Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage UEFI bootloader that is used by Linux distributions to boot the kernel with Secure Boot. But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen. It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.
As commenters on the LWN thread said, I doubt that many firmwares even bother to check anyway. My motherboard happens to have had a bug where you can corrupt the RTC and end up in 2031 if you overclock it wrong. I didn’t use secure boot then though so I don’t know if it would have still booted Windows. But I imagine it would.
That said, I’ve always just enrolled my own keys. I know some other distros that make you enroll their keys as well like Bazzite. At least that way you don’t depend on Microsoft’s keys and shim or anything, clean proper secure boot straight into UKI.
That is far more complex than a firmware update and also depends on a correct implementation of the spec in the BIOS - which, given the experiences with ACPI for Linux, is not at all something one can rely on.
It has nothing to do with ACPI whatsoever. And firmwares this broken are the exception not the rule.
ACPI, especislly as it was at the beginning, is a good example that formally having a spec does not guarantee interoperability: You might get running Linux on some Laptop, but this does not guarantee that essential things like power management work.
Seems it compares the expiration date of the UEFI key with the signature date of the bootloader / OS keys. (See the comments on the LWN article, some are far more knowledgeable than I am.) So, no, it does not require a working on-board clock to lock you out if you are not extremely careful and fully understand each part.
The whole point of the article is that you do depend on their expired root key. You have produced a lot of text without even understanding the key issue. At that point I am wondering whether all that text was produced by an LLM?
I don’t know that you’ve understood the issue either, and you’re being kind of a jerk? My understanding is this mainly affects installation media. If you disable Secure Boot, install a Linux distro, enrol that distro’s keys and then reenable it, you’re fine. That seems to be what the commenter you’re replying too is suggesting.
Yeah this is an issue but not a big one. Most distro’s installation media don’t use shim so you have to disable SB during install anyway.
And installing the 2023 KEK and db certs can be done via firmware without much trouble or you can use
sbctlin setup mode which I believe has both the 2011 and 2023 keys.If you dual boot Windows you’ll want to update it to the new bootmgr signed with the 2023 keys and add the 2011 certs to dbx to protect against BlackLotus or let Windows do it via patches+regfixes.
Also know that any changes to PK, KEK, dB, or dbx will change the PCR 7 measurement so handle that accordingly if you use TPM unlock for FDE.
Please don’t troll and come back to the topic. GP was completely missing the topic, do you want to avoid it?
Um, given that Secure Boot prevents any modification of your computer’s boot chain - including installing another boot loader or OS - that’s not how it works.
Secure Boot does no such thing. All it does it require that everything in the boot chain is signed by a trusted cert.
Binding TPM PCR7 to FDE (or more brittle options like 0+2+4) is really what protects against boot chain modifications but that’s another topic.
Disabling SB to install the distro, then re-enabling it once installed with either maintainer-signed shim or self-signed UKI/bootloader is perfectly fine.
I’m not trolling, you called them an LLM, they clearly aren’t, you’re being a jerk. I’m not going to engage with someone who thinks they’re the smartest person in the room.
That’s the whole point of enrolling your own keys in the firmware. You can even wipe the Microsoft keys if you want. You do that from the firmware setup, or within any OS while secure boot is off (such as
sbctlon Linux).That’s a feature that is explicitly part of the spec. The expectation is you password protect the BIOS to make sure unauthorized users can’t just wipe your keys. But also most importantly that’s all measured by the TPM so the OS knows the boot chain is bad and can bail, and the TPM also won’t unwrap BitLocker/LUKS keys either.
Secure boot is to prevent unauthorized tampering of the boot chain. It doesn’t enforce that the computer will only ever boot Microsoft-approved software, that’s a massive liability for an antitrust lawsuit.
That does not help if the master key in the key chain is expired.
Sure you can disable Secure Boot. But a password-protected BIOS is secured by TPM again. High levels of security always carry a risk of locking oneself out.
I don’t think you understand what “enrolling your own keys” means in the context of Secure Boot.
The key affected here is specifically for the Linux shim signed by Microsoft. It is used by GRUB and some distros to work with Secure Boot.
Enrolling your own key means you add a new certificate to the key store. This is completely separate from the one provided by Microsoft and controlled only by you. The common recommendation is to remove all built-in keys and only add your own, to make this system as secure as possible.
OK, now you are talking about something a bit different - registering own keys in the UEFI system, which is significantly more involved than updating the BIOS, and also requires firmware support, and the firmware also needs to match the motherboard. And the whole issue with ACPI support for Linux shows clearly that having reams of specufications is not enough, the implementation of the BIOS needs to match that specification which whether thsz’s the case you will only learn after you bought the hardware.
Here is a description of that process:
https://docs.bell-sw.com/alpaquita-linux/latest/how-to/use-own-keys-in-secureboot/
Moreover, for any change of the boot chain, bootloader, posdibly also kernel, this needs to be repeated.
Do you think that’s accessible to normal users? Considering most have probably not even ever done a firmware update?
From the first post in this chain
I didn’t start talking about it, this was many comments above
And exactly that Linux shim signed by Microsoft is no longer valid because the Microsoft signature in the UEFI firmware is expired.