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.
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.
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.
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.
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.