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.
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).
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.
This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
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.
Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?
> vendor-selected boot certificates that can't be changed
That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA certs from your device, HTTPS sites will stop working. However, nothing is stopping you from adding your own keys to the system and signing your own software with it.
> happens with every other smartphone, gaming console, car, and even some PCs
How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
> the target of this attack is user freedom and choice.
Which is exactly why users have the freedom and choice to just disable Secure Boot?
and secure boot is still the antichrist, but we have to live with them.
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.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
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.
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.
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.
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.
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.
Windows 10 and then 11
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.
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).
It certainly wouldn't be the first evidence of that…
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 :)
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.
Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
Check its various options
The 'Validity' field in the output will tell you the expiration date.
Qualifier: for personal computers that you don't take regular backups of, test backups, etc
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.
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?
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.
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...
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.
crinkly•3h ago
jeroenhd•15m ago
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.