Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!
Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).
jeroenhd · 2h ago
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.
In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.
In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
RedShift1 · 1h ago
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces.
In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.
m4rtink · 3m ago
Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices.
As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
tliltocatl · 43m ago
That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. APCI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird trocks since Win95 or so).
msgodel · 1m ago
You do also need to assist the OS in doing hardware probing. Even older BIOS systems had ACPI and other standards.
hypercube33 · 21m ago
EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.
numpad0 · 46m ago
There is no basic firmware maintenance to do. Firmware is supposed to be properly engineered, immutable, still to this day sometimes physically wired as 1s and 0s. It doesn't make sense to have expiry dates carved in stone.
mkj · 21m ago
What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)
account42 · 1h ago
No, the real mistake was putting the root of trust anywhere else than the user.
nirui · 2h ago
I'm feeling/guessing the expiration is more of a flow-with-tradition thing. TLS certificates expires, it's part of the security feature, so why not Secure Boot certificates too?
And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft.
However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
semi-extrinsic · 2h ago
> Really it seems like having any expiry date for these certificates is a mistake.
Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
littlestymaar · 3h ago
Is that really a mistake? Or Microsoft just has no interest to care about computers not working as intended anymore.
It certainly wouldn't be the first evidence of that…
pjmlp · 3h ago
Being cynic, there was the expectation that computers would get replaced before the certification expiration date.
greatgib · 5h ago
It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.
sugarpimpdorsey · 4h ago
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority.
Microsoft showed they can semi-competently run a PKI. The end.
Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
WhyNotHugo · 1h ago
Call me childish, but I don’t want to ask Microsoft to sign a certificate for me before I install software onto my own hardware.
I don’t care if it’s required for every installation of if it’s once per hardware. I want to install software without asking a third party for permission. I want this to be doable entirely offline.
Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
preisschild · 20m ago
> Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
Can't you just remove all CAs from the UEFI and import only your own anyways with most mainboard vendors?
ACCount36 · 3h ago
Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.
froh · 2h ago
mind to elaborate?
I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
the promise of secure boot and trusted computing is backdoor-free boot.
what is in your eyes evil and garbage about that?
ACCount36 · 2h ago
Who controls the fucking certs?
"My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards.
"My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartphone, gaming console, car, and even some PCs.
"Trusted Computing" is, and always was, about making sure that the user doesn't actually own his device. This is the real, tangible attack vector - and the target of this attack is user freedom and choice.
preisschild · 20m ago
> Who controls the fucking certs?
You can? Delete the default (ie Windows certs) and import your own.
zozbot234 · 2h ago
> I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.
fsflover · 2h ago
Consider using Heads with TPM and Librem Key to detect possible compromise of your boot stage. It doesn't obey MS but you.
flexagoon · 2h ago
With Heads, the firmware measures itself and sends the results to the TPM. If an attacker flashes a modified firmware that simply lies about the measurement results, the entire security system will be bypassed.
Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.
orrr we just have official institutions which do this and enforce vendors to add certificates from other trusted parties. not only microsoft is able to do this. also microsoft already also had fallout regarding signing.
and secure boot is still the antichrist, but we have to live with them.
littlestymaar · 3h ago
> Now had the Linux folks stepped up to the plate early on, instead of childishly acting
This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
nine_k · 4h ago
Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden.
AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
blkhawk · 4h ago
Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. Secondary was in my opinion better security for handheld phones and tablets running x86 but there the "App store" aspect is even more clear.
"attacker tampers with your system" does not happen at least in the way you think it does or it does not protect you against meaningful attack at all.
pdimitar · 2h ago
What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?
magicalhippo · 8m ago
> Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.?
The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.
cesarb · 28m ago
> What kinds of attacks was Secure Boot designed to mitigate?
Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.
jeroenhd · 2h ago
Evil maid and rootkits, mostly. It's also part of the trust chain that unlocks an encrypted disk without having to enter a password.
On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).
blkhawk · 2h ago
That is sorta the rub - the treat profile "evil maid" is mainly governmental actors for most people even for Orgs. Your example shows mostly how an org can secure their own devices against casual misuse by unprivileged users.
This does not help against any serious attack. It only protects against stuff you don't need to worry about generally.
oakwhiz · 4h ago
We don't even reap the benefits of autocratic decisions from Microsoft in this area. Boards always come out with things like messed up ACPI, etc.
p_l · 3h ago
Boards' ACPI etc. is still better than what it would be without "certified for Windows" (whatever name of the hour is) programs
whatagreatboy · 4h ago
Only legal requirements can change it. Nowadays, the mokutil is good enough that linux users can build a good tool around it to automate registration at boot that should ease some pain. But otherwise, it is a big mess and still needs legal requirement.
ChocolateGod · 4h ago
But you can turn it off or en-roll your own keys.
EnPissant · 2h ago
It's just a default. You can override it with your own platform key.
jeroenhd · 2h ago
I wonder what my laptop will do soon.
Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change.
Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.
laserbeam · 1h ago
The article should include a very obvious way for someone to test if they are affected. How does one verify (in an in a VERY clear and straightforward way) if some arbitrary system will run into this issue in September?
mkj · 24m ago
Set your clock to December, reboot, and see what happens.
saidinesh5 · 5h ago
Just out of curiosity, how good is the secure boot experience these days?
I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
paulv · 4h ago
My experience as a long time Linux user (since 1997, so admittedly stuck with some bad habits from when things were actually hard to get working) has been that things are kind of confusing if you deviate from the golden path, but if you are on the golden path you won't ever notice that it is turned on.
The laptops I have gotten from eg Dell with Linux pre installed have just worked. Machines I have upgraded through many versions of Ubuntu (lts versions of 16-24) were weirdly broken for a while when I first turned secure boot on while I figured it out, but that seemed reasonable for such a pathological case. Machines I have installed Debian on in the last few years have been fine, except for some problems when I was booting from a software raid array, but that is because I was using 2 identical drives and I kept getting them confused in the UEFI boot configuration.
I have not used them on machines with nvidia, vbox, or other out-of kernel-tree modules though.
michaelt · 3h ago
I would rate the experience as 6.5/10
If you use a major distro like Ubuntu, you might find Secure Boot works out-of-the-box, with no need to dick about with 'machine owner keys' and suchlike.
Ubuntu has packages like "linux-modules-nvidia-550-generic" containing a version of nvidia's 550 drivers signed with canonical's keys. If the stars align and that package gets installed, you'll have nvidia drivers that work under secure boot.
They also have a second mechanism. You can set up a 'machine owner key' (MOK) then software updates will trigger automatically building new nvidia kernel modules, using 'dkms' then sign them with the MOK allowing them to work under secure boot.
The problem is this process can be a bit wonky. The MOK setup process involves rebooting and going through the "MOK Manager", an interface that looks like something from the 1980s. If you didn't know to expect it, or what it's there for, or you don't speak English, it's easy to hit the wrong thing and not set up your MOK. And it only shows up for a single boot, unless you know an arcane terminal command.
And if you run into any problems during the setup process - you're going to be researching the fix on your phone, because your PC isn't booting.
Meanwhile, the third option of just turning off secure boot is easy (assuming you know what the BIOS is) and it works every time. So a lot of 'how to set up nvidia drivers' guides just recommend doing that.
Although I complain about it, I find it impressive things like dynamically compiling and signing kernel modules works as well as it does - especially as so much of it is maintained by volunteers, selflessly giving up their free time when they could have simply turned off secure boot in their BIOS too.
pbhjpbhj · 4h ago
Every couple of years MS do an update that messes up multi-boot/dual boot. I'm sure it's on purpose at this point, and relatively sure "Secure Boot" is how they achieve it.
Still on Windows only for kids games. Linux user since last millennium.
blkhawk · 3h ago
As a Linux-only gamer since 2019 I wonder what kids games you are talking about?
repstosb · 3h ago
There are things like Roblox that are really only usable under Windows due to a perverse idea of what "anti-cheat" should look like.
ah, I almost mentioned roblox but checking protondb it has gold status. So it should work?
ChocolateGod · 3h ago
> Every couple of years MS do an update that messes up multi-boot/dual boot
IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.
account42 · 39m ago
The idea that MS should be able make orders that distros then have to follow is insane. If MS breaks something it absolutely is their fault.
noAnswer · 36m ago
So Windows installs something that brakes Linux boot. How are you supposed to boot Linux to install a fix? Am I expected to reboot into a different OS twice a day and check for updates? Am I slacking for not doing so?!
bravetraveler · 5h ago
Signature maintenance for modules can be fully automated. Enrollment requires navigating a mildly-intimidating interface a single time to accept the new PKI.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
mormegil · 4h ago
Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?
ChocolateGod · 3h ago
Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).
vbezhenar · 1h ago
There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though.
1. You can sign and verify initramfs, it's supported by bootloaders.
2. You can merge kernel and initramfs into UKI and sign the whole image.
I don't know why that's not implemented.
the8472 · 2h ago
With a UKI the initramfs gets signed too, doesn't it?
bravetraveler · 3h ago
Aye, though an evil maid has higher barriers and more paperwork in a DC.
I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
michaelt · 3h ago
> Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it?
One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"
But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.
Of course if your server has a KVM attached, you can still do this remotely, I guess.
chaz6 · 3h ago
I use Fedora and have it enabled. Every time there is a kernel update I have to run a script to re-compile and sign the vmware drivers. I could probably figure out how to do it with dkms at some point. Every now and then, there's a kernel change big enough to make the vmware drivers stop working so I have to get a new patch.
jeroenhd · 2h ago
It works pretty well out of the box unless you're trying to combine Linux with Nvidia hardware. Even with Nvidia hardware it doesn't take that much effort to make it work, but as usual, Nvidia requires taking extra steps.
What Linux is really lacking is a user-friendly method for enrolling your own keys, which would instantly solve all the Nvidia/firmware updater/custom bootloader problems. The command line tools are slowly getting easier to use, but there's no guided instruction flow.
vbezhenar · 1h ago
I'm using Arch and it was very easy to configure secure boot. I don't know why you think it's not friendly. I'm using UKI, so no bootloader at all, my UKI is signed by my own key which is installed into UEFI. Most of sign process is handled by systemd, so most of it is already integrated into the base system.
icar · 3h ago
With Arch, I've been using SecureBoot since sbctl [0] was released with 0 issues. Granted, I don't use any Nvidia hardware.
just doublechecked with "Confirm-SecureBootUEFI" - says True on my laptop which used > 1 year. I'm pretty sure on the previous system which was used for 4 years it was on too - have not noticed any issues.
Windows 10 and then 11
EnPissant · 2h ago
UKI + secure boot works really well, but it is somewhat manual of a set up on Arch (what isnt).
If properly set up the only files you generate are:
- /efi/loader/random-seed
- /efi/EFI/Linux/arch-linux.efi
- /efi/EFI/Linux/arch-linux-fallback.efi
and the .efi are all automatically signed by hooks.
You can even skip a bootloader and boot the images directly.
palata · 2h ago
[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already]
I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly:
1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).
2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).
Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?
eqvinox · 1h ago
> It sounds like the "manufacturer keys" are always from Microsoft,
The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.
palata · 1h ago
And next to those you can load your custom keys?
eqvinox · 1h ago
You need to replace the PK with one of your own, because that is used to sign all the other keys, and generally there can only be one PK. You can then re-sign the existing keys with your own PK (e.g. if you want to dual boot Windows) — or just ditch the existing ones¹, and/or you can generate your own keys of the other types (KEK & DB).
Ed.: ¹ there are cases where ditching the existing keys breaks the system, because the board vendor was stupid and signed the VGA UEFI driver with one of those keys instead of tying it directly into the BIOS/UEFI image. AFAIK this only affects a specific series of Lenovo laptops, but Google the details before breaking your system.
Ed.#2: actually I think the PK signature is only checked while installing keys into the KEK/DB list, so you don't need to re-sign the existing Microsoft keys, they just stay in the list by default. (Unless they got cleared somehow.) It's been a little while since I did this.
vbezhenar · 2h ago
Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys.
Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.
palata · 1h ago
> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys
Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?
Would the solution be that the GPU should load the firmware from the OS?
jeroenhd · 2h ago
> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
palata · 2h ago
> AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted.
You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.
> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
omnibrain · 3h ago
I'm sure this is a naive take, but why is it not possible to enter a new key into the BIOS (dating myself, I know it's EFI) by hand?
eqvinox · 1h ago
It's possible and it's what you should be doing. "sbctl" (https://github.com/Foxboron/sbctl) AFAIK has a reasonable frontend for doing that on Linux (don't know, I did it manually). You have to put the system in "secure boot setup mode" in BIOS/UEFI options before booting, which enables changing the PK (Platform Key) which is used to chain off all the other keys. (Setup mode should be automatically exited when you install a new PK.)
You can keep the Microsoft keys in there if you want to dual boot Windows, you just need to re-sign the keys themselves with your own PK.
jcgl · 2h ago
It should be, at least on higher-end boards, no?
nottorp · 3h ago
You'd have control over what boots on your computer then...
ozgrakkurt · 3h ago
That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon
I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
nicman23 · 3h ago
you literally have though. you can self sign everything and set up uefi to only boot your signature
nicman23 · 3h ago
it is
negative_zero · 4h ago
Well I can say that the update is not going 100% smoothly. I have a pending KEK update in Fedora but it's a test key (bug filed but no progress as of yet).
crinkly · 5h ago
So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.
jeroenhd · 2h ago
If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires.
If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires.
If users do update their systems and software, Grub will keep working.
Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
zozbot234 · 1h ago
> Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.
xiconfjs · 3h ago
Is there a reliable command in Ubutu to check for the secure boot key and its expiration date?
porridgeraisin · 2h ago
mokutil
Check its various options
The 'Validity' field in the output will tell you the expiration date.
eqvinox · 1h ago
mokutil is technically the wrong tool for this, it lists shim-installed machine owner keys (MOK). This is about UEFI-installed key exchange keys (KEK). If you don't know what's going on you'll be very confused about empty key lists. It can in fact show KEKs but you need to know that this is a KEK thing to begin with…
mokutil --kek | egrep '(Not |Subject:|^[^ ])'
is the magic incantation if you really want to use mokutil
chabad360 · 2h ago
It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone being the wiser.
The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system.
SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.
xyst · 2h ago
Reading into the history of Secure Boot. Discovered Intel and AMD processors have back doors via Intel Management Engine [1] and AMD Platform Security Processor [2]. Both are closed source and have had a number of vulnerabilities over the years. They are essentially backdoors.
Seems disabling these "features" is nearly impossible as well.
> 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.
No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?
porridgeraisin · 2h ago
Secure boot, disk encryption, etc are more trouble than they are worth IME. I have them all off.
Qualifier: for personal computers that you don't take regular backups of, test backups, etc
flexagoon · 2h ago
Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen.
I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
zozbot234 · 1h ago
SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.
Artoooooor · 4h ago
Just another factor creating electro-junk. Currently I can install 30 year old system on 30 year old hardware (assuming that I keep both the machine and the installation media in a good shape). With current computers it will be impossible because they will be "unsupported".
jeroenhd · 2h ago
Just disable secure boot if you can't update the certificate. You can still use your computer.
TacticalCoder · 2h ago
> Any installed distribution should have a bootloader signed with its own key that will continue to boot
I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows).
So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring).
Am I correct in my understanding that this only affects my installation media and not my already installed systems?
Lastest Debian stable FWIW.
Oh well, I take it it's going to be mokutil and whatnots when I get back home.
roschdal · 4h ago
Secure boot is so evil.
eqvinox · 1h ago
No it's not. Secure boot without user control is evil. UEFI generally allows user control. Of course a vendor can make an UEFI system that doesn't allow user keys… don't buy that.
https://support.microsoft.com/en-us/topic/windows-secure-boo...
https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!
Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).
In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.
In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.
As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft.
However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
It certainly wouldn't be the first evidence of that…
Microsoft showed they can semi-competently run a PKI. The end.
Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
I don’t care if it’s required for every installation of if it’s once per hardware. I want to install software without asking a third party for permission. I want this to be doable entirely offline.
Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
Can't you just remove all CAs from the UEFI and import only your own anyways with most mainboard vendors?
I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
the promise of secure boot and trusted computing is backdoor-free boot.
what is in your eyes evil and garbage about that?
"My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards.
"My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartphone, gaming console, car, and even some PCs.
"Trusted Computing" is, and always was, about making sure that the user doesn't actually own his device. This is the real, tangible attack vector - and the target of this attack is user freedom and choice.
You can? Delete the default (ie Windows certs) and import your own.
Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.
https://forum.qubes-os.org/t/discussion-on-purism/2627/187
https://forum.qubes-os.org/t/discussion-on-purism/2627/177
and secure boot is still the antichrist, but we have to live with them.
This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
"attacker tampers with your system" does not happen at least in the way you think it does or it does not protect you against meaningful attack at all.
The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.
Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.
On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).
Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change.
Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.
I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
The laptops I have gotten from eg Dell with Linux pre installed have just worked. Machines I have upgraded through many versions of Ubuntu (lts versions of 16-24) were weirdly broken for a while when I first turned secure boot on while I figured it out, but that seemed reasonable for such a pathological case. Machines I have installed Debian on in the last few years have been fine, except for some problems when I was booting from a software raid array, but that is because I was using 2 identical drives and I kept getting them confused in the UEFI boot configuration.
I have not used them on machines with nvidia, vbox, or other out-of kernel-tree modules though.
If you use a major distro like Ubuntu, you might find Secure Boot works out-of-the-box, with no need to dick about with 'machine owner keys' and suchlike.
Ubuntu has packages like "linux-modules-nvidia-550-generic" containing a version of nvidia's 550 drivers signed with canonical's keys. If the stars align and that package gets installed, you'll have nvidia drivers that work under secure boot.
They also have a second mechanism. You can set up a 'machine owner key' (MOK) then software updates will trigger automatically building new nvidia kernel modules, using 'dkms' then sign them with the MOK allowing them to work under secure boot.
The problem is this process can be a bit wonky. The MOK setup process involves rebooting and going through the "MOK Manager", an interface that looks like something from the 1980s. If you didn't know to expect it, or what it's there for, or you don't speak English, it's easy to hit the wrong thing and not set up your MOK. And it only shows up for a single boot, unless you know an arcane terminal command.
And if you run into any problems during the setup process - you're going to be researching the fix on your phone, because your PC isn't booting.
Meanwhile, the third option of just turning off secure boot is easy (assuming you know what the BIOS is) and it works every time. So a lot of 'how to set up nvidia drivers' guides just recommend doing that.
Although I complain about it, I find it impressive things like dynamically compiling and signing kernel modules works as well as it does - especially as so much of it is maintained by volunteers, selflessly giving up their free time when they could have simply turned off secure boot in their BIOS too.
Still on Windows only for kids games. Linux user since last millennium.
IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
1. You can sign and verify initramfs, it's supported by bootloaders.
2. You can merge kernel and initramfs into UKI and sign the whole image.
I don't know why that's not implemented.
I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"
But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.
Of course if your server has a KVM attached, you can still do this remotely, I guess.
What Linux is really lacking is a user-friendly method for enrolling your own keys, which would instantly solve all the Nvidia/firmware updater/custom bootloader problems. The command line tools are slowly getting easier to use, but there's no guided instruction flow.
[0] https://github.com/Foxboron/sbctl
Windows 10 and then 11
If properly set up the only files you generate are:
- /efi/loader/random-seed
- /efi/EFI/Linux/arch-linux.efi
- /efi/EFI/Linux/arch-linux-fallback.efi
and the .efi are all automatically signed by hooks.
You can even skip a bootloader and boot the images directly.
I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly:
1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).
2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).
Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?
The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.
Ed.: ¹ there are cases where ditching the existing keys breaks the system, because the board vendor was stupid and signed the VGA UEFI driver with one of those keys instead of tying it directly into the BIOS/UEFI image. AFAIK this only affects a specific series of Lenovo laptops, but Google the details before breaking your system.
Ed.#2: actually I think the PK signature is only checked while installing keys into the KEK/DB list, so you don't need to re-sign the existing Microsoft keys, they just stay in the list by default. (Unless they got cleared somehow.) It's been a little while since I did this.
Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.
Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?
Would the solution be that the GPU should load the firmware from the OS?
AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.
> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
You can keep the Microsoft keys in there if you want to dual boot Windows, you just need to re-sign the keys themselves with your own PK.
I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires.
If users do update their systems and software, Grub will keep working.
Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.
Check its various options
The 'Validity' field in the output will tell you the expiration date.
The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system.
SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.
Seems disabling these "features" is nearly impossible as well.
[1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine
[2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...
No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?
Qualifier: for personal computers that you don't take regular backups of, test backups, etc
I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows).
So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring).
Am I correct in my understanding that this only affects my installation media and not my already installed systems?
Lastest Debian stable FWIW.
Oh well, I take it it's going to be mokutil and whatnots when I get back home.