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.
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.
well said
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.
Here
https://en.m.wikipedia.org/wiki/UEFI#Secure_Boot_criticism
is a list of problems and criticism on Secure Boot.
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.
thus turning computers into phones, where you have to do a complicated unlocking/rekeying process to install your own OS.
On ARM, you evrn can’t disable Secure Boot.
That’s bullshit. ARM is an architecture and by itself does not specify secure boot any more than x86 does. Raspberry Pis don’t have secure boot. You can unlock the bootloader on a Pixel, install GrapheneOS, and relock the bootloader just fine. Several other manufacturers allow bootloader unlocks no problem. The main reason you can’t on some popular phones is US carriers, even international Samsungs you can unlock the bootloader and flash whatever you want on it.
I’m literally typing this comment on a phone running a custom OS (LineageOS on a OnePlus 8T). I’m literally 2 versions of Android ahead of the latest supported version. I also have a Galaxy S7 running Android 15, a phone that officially tops out at Android 8 and launched with Android 6. Both you literally just toggle the bootloader unlock option in the settings, no hacks no craziness, it’s literally a feature.
At this point you’re just straight up making shit up.
That’s bullshit. ARM is an architecture and by itself does not specify secure boot any more than x86 does. Raspberry Pis don’t have secure boot.
I mean Windows PCs with ARM CPUs which have Secure Boot, not Android smart phones or embedded devices.
Nope. Even Qualcomm themselves provide what’s needed to run Linux on the Windows for ARM PCs.
The only one I can’t find for sure is whether there’s any lockdown on the firmware for the Microsoft Surface and Copilot+ laptops, but I’m also not finding any sources pointing that it would be. But at this point you’re buying Microsoft hardware, what do you expect.
I thought it was a Microsoft centric thing in that the certificate authority was either Microsoft or signed by Microsoft?
Maybe I need to read about it more? Can you direct me to the general area?
Microsoft’s keys are pre-installed to all motherboards, so boot binaries signed by Microsoft are trusted by default. afaik Microsoft keys often can’t be removed, but not because it’s not possible, but because it can brick devices. you can create your own MOK or Machine Owner Keys and set up your linux system to sign your bootloader and kernel with it, but that is in addition to Microsoft keys.
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
Thank-you. Recently rebuilt my Arch Rescue build and saw that section in doing the UKI dance.
I don’t mind the Microsoft keys being there at all. I just don’t think tying myself to them is particularly clever.
From your final part. I think I need to go back and reread it. Thank-you again.
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 said, I’ve always just enrolled my own keys.
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 works.
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.
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.
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.
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.
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 said, I’ve always just enrolled my own keys.
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
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.
I didn’t start talking about it, this was many comments above
The key affected here is specifically for the Linux shim signed by Microsoft.
And exactly that Linux shim signed by Microsoft is no longer valid because the Microsoft signature in the UEFI firmware is expired.
I think this already bites people, it has started, it’s not in September but now?: https://x.com/rogerioperdiz/status/1946873449537798582
I just tried to distro-hop and found my BIOS had been locked with a password. Assuming I didn’t set a password that I subsequently forgot (and that isn’t one of the many I have memorized), I figured this might have something to do with the age of the laptop (I have a HP 4540s). If certificate expiration is already affecting people then this might be it.
EDIT: I just forgot I set a password, and it took me 2 days to realize that I was stupid enough to have set the password that I used for everything when I was 12 years old.
How did you bypass the password?
Not OP, but BIOSes often give you a specific error code after a few wrong password attempts. You can put the code in here to recover the password: https://bios-pw.org/
I didn’t. And apparently you can’t without trying to short-circuit the motherboard. I just assumed, and assumed wrong.
The details are complex; it has humorously been called “security by security”.
Hobby Linux users could, as far as I understand , simply disable UEFI secure boot (after weigthing carefully what secure boot provides to them, and what it does not provide). Otherwise, they’ll need a firmware upgrade before any upgrade to a new OS / bootloader chain.
Small companies which use old laptops with Windows might be bitten hard by this because they can become locked out of their hardware with no way to update it, or even make a backup!
And by the way, Intel motherboards which are running your Linux system may contain a copy of Minix - yes, the Minix from the historic Tanenbaum vs. Torvalds debate - which runs below the OS in the system management mode engine and is controlled by the vendor, which can e.g. update firmware via the network. SMM is normally not visible by the user but it can cause problems e.g. for real-time applications because it has higher privileges than the kernel and can interrupt all of the kernel at any time.
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.
If secure boot is off, and you run malware on your pc, it can change the boot process to escalate privileges.
This probably requires root or admin in the first place, but if they can install a malware loader, they can establish persistence so that even if you remove the os-level components, they’ll be reinstalled on reboot.
If secure boot is off, and you run malware on your pc, it can change the boot process to escalate privileges.
This is technically correct, but on a desktop system, malware executing in user space is normally already game over. It can exfiltrate and send your passwords, change browser certificates or browser software, add user systemd sesdions or crontab entries and can generally e.g. do everything a banking trojan would like to do.
Yeah, but the malware can just wait for a system upgrade where you sign a new boot image and slip itself in then.
It works for Windows because theoretically only Microsoft would have the signing key and it’s not just sitting on disk somewhere. But then you’re just trusting Microsoft, and also subject to vendor lock-in.
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.
You need both FDE and Secure Boot, ideally with FDE using a TPM with PIN and PCR 7+15=0. FDE without SB can be trivially boot-kitted and obviously SB without FDE is mostly pointless. Maybe for a server/desktop behind locked doors you don’t worry as much, but for a laptop you absolutely should. Also it’s really easy in Arch to resign the UKI with sbctl via a pacman hook whenever the kernel is updated so there’s no good reason not to use it.
If you’re relying on a LUKS password only, it can be brute-forced. To protect against that you need a decently long password which is annoying to type every boot. A short TPM PIN sealed by SB protecting LUKS is both more convent and more secure.
Finally, if an attacker or malware gets root, FDE isn’t protecting you either.
Even having no pre-boot PIN with SB on is nice, then you only need your user space login where you could even use fingerprint reader if you like. For servers they can already start serving without anyone having to intervene manually (which is nice after power outage, for example).
So yeah, SB, TPM and FDE are a very nice bundle that heavily secures against the most relevant attack vectors.
Yep that’s how my desktops and servers are set up. I only recently started adding the TPM PIN to my laptops for a bit of extra protection from cold boot / evil maid attacks.
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).
There’s nothing technically preventing using TPM without secure boot. This is a limitation imposed by OEMs. In fact I have a separate hardware encryption key that I encrypt my (laptop) drive with, and even I don’t (can’t) know the private key. I only know the pin that is needed to unlock it. If motherboard OEMs implemented something like this on the motherboard, with the ability to decrypt the bootloader partition before booting into it, this would solve everything.
