Most active commenters

    ←back to thread

    Linux and Secure Boot certificate expiration

    (lwn.net)
    253 points pabs3 | 13 comments | 18 Jul 25 03:53 UTC | HN request time: 1.593s | source | bottom
    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 #
    1. 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 #
    2. 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).
    3. hypercube33 ◴[18 Jul 25 11:48 UTC] No.44603658[source]▶
    EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.
    replies(1): >>44673210 #
    4. m4rtink ◴[18 Jul 25 12:06 UTC] No.44603786[source]▶
    Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices.

    As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.

    5. msgodel ◴[18 Jul 25 12:08 UTC] No.44603793[source]▶
    You do also need to assist the OS in doing hardware probing. Even older BIOS systems had ACPI and other standards.
    6. jeroenhd ◴[18 Jul 25 12:58 UTC] No.44604202[source]▶
    UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.

    You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.

    I'll take UEFI over BIOS any time if only because it finally solved dual booting.

    replies(2): >>44604271 #>>44673176 #
    7. xg15 ◴[18 Jul 25 13:08 UTC] No.44604271[source]▶
    > modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.

    Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?

    This stuff seems inches away from a supply chain attack.

    replies(1): >>44616277 #
    8. OptionOfT ◴[19 Jul 25 15:22 UTC] No.44616277{3}[source]▶
    https://view.officeapps.live.com/op/view.aspx?src=https%3A%2...

    It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...

    9. 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 #
    10. 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 #
    11. Avamander ◴[20 Jul 25 11:07 UTC] No.44623986{3}[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.

    12. hulitu ◴[24 Jul 25 17:06 UTC] No.44673176[source]▶
    > I'll take UEFI over BIOS any time if only because it finally solved dual booting.

    With the BIOS i didn't needed to reinstall the bootloader every time i updated my BIOS. And also it was not updated every 2 months , like current UEFI.

    13. hulitu ◴[24 Jul 25 17:08 UTC] No.44673210[source]▶
    > EFI was part of the itanium culture at Intel

    That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?