←back to thread

Linux and Secure Boot certificate expiration

(lwn.net)
253 points pabs3 | 1 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 #
1. tliltocatl ◴[18 Jul 25 11:26 UTC] No.44603474[source]▶
That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).