←back to thread

Linux and Secure Boot certificate expiration

(lwn.net)
253 points pabs3 | 2 comments | 18 Jul 25 03:53 UTC | HN request time: 0s | source
Show context
mkj ◴[18 Jul 25 07:23 UTC] No.44602124[source]▶
It's not just Linux - certificates to sign Windows are also affected in 2026.

https://support.microsoft.com/en-us/topic/windows-secure-boo...

https://techcommunity.microsoft.com/blog/windows-itpro-blog/...

Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!

Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).

replies(5): >>44602428 #>>44602690 #>>44602733 #>>44602895 #>>44617707 #
jeroenhd ◴[18 Jul 25 09:24 UTC] No.44602733[source]▶
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.

In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.

In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

replies(5): >>44603271 #>>44603290 #>>44603448 #>>44603660 #>>44604239 #
RedShift1 ◴[18 Jul 25 10:58 UTC] No.44603271[source]▶
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces.

In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.

replies(6): >>44603474 #>>44603658 #>>44603786 #>>44603793 #>>44604202 #>>44617759 #
DSMan195276 ◴[19 Jul 25 17:58 UTC] No.44617759[source]▶
The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.
replies(1): >>44618561 #
1. RiverCrochet ◴[19 Jul 25 19:32 UTC] No.44618561[source]▶
All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to support DOS or because of DOS. APM leveraged SMI for fan and power control so DOS would work on 90's era laptops. That whole mess morphed into the nightmare of ACPI and UEFI.

The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer.

A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.

replies(1): >>44623986 #
2. Avamander ◴[20 Jul 25 11:07 UTC] No.44623986[source]▶
> Linux lets you build a devicetree as part of the kernel.

And it's absolutely awful as an end user if you have anything even slightly unusual.