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.
deleted by creator
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.
deleted by creator
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.
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 work.
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.
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?
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.
I think this already bites people, it has started, it’s not in September but now?: https://x.com/rogerioperdiz/status/1946873449537798582
