Windows Secure Boot Kills Linux on June 24th! (YouTube video)
Assuming you make the mistake of using “Secure” Boot.
My understanding is that secure boot being enabled is the default. More and more non-technical people are moving to Linux (largely because Microsoft has obsoleted so much hardware). These people won’t even know what secure boot is or even that it exists or that they can disable it in something called a BIOS.
Although this does raise the question as to whether or not those obsoleted machines even use secure boot. I don’t know the answer to that.
I’ve long embraced the usefulness of being able to boot Microsort’s operating systems, but I’ve never owned a Windows PC, unless you count the Intel-based Macs.
The safest way to run Windows is in a virtual machine or emulator.
I have a couple of “obsoleted” machines in my stable that boot out of UEFI and are capable of Secure Boot, but since they’re not prebuilts “market default” has no applicability. I configure them as I choose, not some OEM beholden to Microsoft.
But I’m not the user you’re worrying about.
There probably will be a lot of Windows users who’ll be quite put out when their machine fails to boot.
As for myself, I will need to check on a couple of Windows 11 gaming laptops my kids have. They’re probably Secure Boot defaulted and I’ll want to get them ready for the transition.
Regarding Linux, at least, expiration day won’t be Judgment Day. Nothing changes until the system gets an updated version of the UEFI boot shim, which is not a change driven by the key expiration but affected by it.
The short version is this: systems using existing shim bootloaders signed with the current Microsoft CA key will remain fully functional after the key expires. Timestamping has your back here. A shim signed before the expiration date retains its validity indefinitely, thanks to mechanisms baked into software signing protocols. The firmware trusts the embedded keys that Secure Boot relies on, and those keys, as a rule, don’t expire.
This being the internet, different sources are saying different things. Some say that it will seamlessly continue to boot but be less secure from here on. Others say that it won’t boot but that you can remedy this by booting into the BIOS and disabling secure boot (leaving you less secure) and others seem to imply that the system will be hopelessly bricked (which I suspect is the least likely scenario).
I have checked various sources I find reliable (including Linux distros themselves) and they all agree that it will not actually affect existing installations.
What is happening is that Microsoft will no longer sign new Linux bootloaders with these old keys. As such, to run new bootloaders, your system will need a BIOS update to add new keys to SecureBoot.
Your current installation will not be less secure than it was before. It’s just that the old keys are less secure than these newer ones. And new bootloaders with these keys will not work.
I’m still confused. When are new bootloaders installed? Will they be installed with Windows updates, when you get the newest Linux upgrades, or are they something that can be avoided indefinitely? Will new machines have newer bootloaders that will prevent booting into Linux? Is this a problem only if you have new bootloaders but an older version of Linux? Will machines configured for dual-booting still be able to boot into Windows but not into Linux?
What scenarios, if any, will stop machines from booting?
This is an explanation of secure boot, and what is happening.
- UEFI secure boot
- signed shim
- grub or other bootloader
- Linux kernel
- grub or other bootloader
- signed shim
Trusted root certificates live in the UEFI secure boot, and Microsoft must sign the shim. The shim contains a trusted certificate from the distribution (Ubuntu, RedHat, Debian, etc.). Grub and the kernel are then signed with the trusted distribution certificate.
So trust goes like:
- Your computer trusts Microsoft
- Microsoft trusts RedHat (etc.)
- RedHat provides a signed grub and kernel
- Microsoft trusts RedHat (etc.)
so with a complete chain of trust, your computer knows that the kernel as provided is the one that RedHat distributed, and it has not been modified by a someone else.
What is happening is that the certificate Microsoft used to sign the shim is expiring, so RedHat’s key in the old shim will not be trusted to sign new kernels. All that needs to happen is for Microsoft to sign a new shim for RedHat, and RedHat will be able to sign new kernels and bootloaders.
This has already happened. Your distribution will install an updated shim, and new bootloaders and kernels will be signed by the new shim.
You can always create your own certificate and enroll it in your computer, and sign your own kernels. Or just turn off secure boot.
While true, what I read is that the new certificates require the UEFI certificate store to be updated. The most common way for that to happen is for a “BIOS” update, but there is also a workaround if your motherboard is too old or otherwise won’t get any nrew firmware updates.
I put “BIOS” in quotes because we call it that, but motherboard don’t use the BIOS technology anymore. It’s technically a UEFI firmware update for your motherboard.
If I understand it correctly there are two ways. A Windows update can load the new certificates, or a firmware/bios update can load the new certificates. I know on my Dell laptop with Linux I occasionally get updates through fwupd that only update the certificates (the KEK, db, or dbx, which I can’t bothered to lookup what the difference is).
You can also load your own certificate, but I’ve never bothered to go that route, and don’t see an easy way to get the updated Microsoft certificate.
What annoys me is that the new Microsoft certificate was generated in 2023, and the old one expires at the end of June 2026, but the Windows update to load it is from May 2026. Seems like there was lots of time to deal with it. Maybe that means it’s already loaded into the BIOS of lots of computers, but I really don’t know.
I used some commands from this Reddit thread to extract the certificates from my Dell’s firmware, and it does contain the new updated key.
I ran similar commands on a desktop that I put together myself, and it claims to not have any certificates. I’ve never tried secure boot on it, and it’s never run Windows.