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