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.
Being beholden to Microsoft doesn’t sound like something anyone needs.
Until that ends I’m doing best to avoid secure boot. I don’t want to.
You can self-sign and self-enroll secure boot keys. Can’t say it’s an easy process, though - I had a lot of misery with it on my Surface Go 1st Gen. Might be better on my Thinkpad.
Here
https://en.m.wikipedia.org/wiki/UEFI#Secure_Boot_criticism
is a list of problems and criticism on Secure Boot.
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.
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.
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.
At least that way you don’t depend on Microsoft’s keys and shim or anything,
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.
and you’re being kind of a jerk?
Please don’t troll and come back to the topic. GP was completely missing the topic, do you want to avoid it?
. If you disable Secure Boot, install a Linux distro, enrol that distro’s keys and then reenable it, you’re fine.
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.
given that Secure Boot prevents any modification of your computer’s boot chain
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.
Funny how Microsoft does this just before the October EOL deadline for Windows 10, when a whole bunch of hardware is being forcibly obsoleted…
So… microsoft has positioned itself between common users and Linux… and as an authority of sorts.
if only people had predicted this way back when it came out
There is even a whole section in Wikipedia on issues and criticism with secure boot:
https://en.m.wikipedia.org/wiki/UEFI#Secure_Boot_criticism
Some people argue that one can work around such locking down of PC hardware. Do this or that to avoid issues with substantial tinkering.
But that is not a bug but a feature. Sure, as a technical Linux user you can work around some nastiness. Like working around privacy invasion on Facebook or Linkedin by “adjusting” settings, or “adjust” settings in Wimdows to make it more private and so on. The thing is: working against the platform becomes quickly a losing game, because you don’t control the platform - Microsoft does. And it does not help you if you manage to re-gain control of your device after some hours of tinkering if 99.9% of people around you don’t have the knowledge and time and store your data, photos, Emails on OneDrive and so on. Freedom is very much a collective thing and software freedom is no exception.
And this does not mean that the thinkering and hacking is in vain - but it is not enough. We need the practical right to control our devices.
For a home desktop that’s never left unattended with anyone untrustworthy, I don’t see that Secure Boot is worth the effort in setting up.
Given that you have to re-sign the boot image every time you upgrade, any malware already running with root privileges on the machine could easily slip itself into the new signed image.
The best security is not running untrusted software to begin with.
Can you explain the detailed reason why you think that? Voicing opinions is nice of course but explaining the thought process and logic is, I think, almost always more interesting to other people.
To start with, what do you think is the “normal users” threath model? And, for example, if one happens to be a member of any of the various minorities that authoritarian governments of every color happen to single out and persecute in your countries case, what would you want to protect from? Or if you are, say, a lawyer, and have a professional obligation to protect sensitive data from theft?
Actually, I would love for you to explain to me how Secure Boot alone would protect someone from any of that. If you want to protect files, you need full disk encryption, not Secure Boot.
Or are you seriously expecting a government-level threat actor to bother to:
- Sneak into your home while you’re away or asleep;
- Overwrite your bootloader or UEFI with a rootkitted image of the same version so it’s impossible to tell;
- Wait for you to boot your computer and enter your disk encryption password, then:
- Use the rootkit to read the decrypted files off your disk?
That’s the great thing about fascist governments, is they have no need to be that sneaky. They can just change the laws to make whatever you’re doing illegal and jail you until you agree to give up your documents, or simply hit you with a $5 wrench until you tell them the password.
Secure Boot is a really contrived and, frankly, bad defense against an attack that is extremely difficult to execute in reality and does not happen often (are there any examples of a bootloader replacement against a home desktop in the wild?).
An actually good solution would be firmware support for LUKS-style FDE (with a password-encrypted key which then encrypts the rest of the disk), so that your bootloader is encrypted with the rest of your system and impossible to substitute without erasing the rest of the disk, until you enter the password. This way there’s no need for key enrolment into firmware, and firmware manufacturers don’t have to just trust MS. (the firmware of course needs to be protected too, by signing it with the manufacturer’s key; if you flash something unsigned, a warning pops up Android-style before every boot).
If you are hiding something from the state (like your sexual orientation or something), your energy is much better spent encrypting your communications online and keeping your identities anonymous. If you are already suspicious enough to try and pull a bootloader replacement attack on you, any authoritarian state which would do that in the first place will just throw you in jail and fabricate evidence as needed.
The main advantage of SB is TPM. At runtime the key isn’t available and unlocking your disk works automatically as long as nothing has been tampered with (which is then also a nice canary: if you suddenly have to enter your password during boot, something’s off).
