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)
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.
I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
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.
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.
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.
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.
We do use Kubuntu for games that run in it without drama - Risk of Rain, Roblox (via Sober), browser games, CS2.
They also are expected to use Microsoft Office for school (UK), it's possible to work that online, but the experience is worse, slower, more prone to issues it seems.
Fwiw, I've been a Linux distro user for decades and was Linux only until the first child got to highschool. Microsoft's "educational" policy works for them!
Most of the guides focus on creating the PK, KEK, and db certs for enrolling/updating certs from userspace with signed .auth files but that is kind of pointless and seriously over-complicates it. I just created a 20-year db key pair with openssl (and PK and KEK just to make sbctl happy due to a bug), then installed the public db cert into the UEFI manually via the ESP. Didn't even need to use setup mode, although I suspended BitLocker on the Windows partition to let it reseal its key with the new PCR 7 measurement after the db update.
To finish securing it I have a separate key for PK and KEK and have already installed Microsoft's 2023 UEFI certs in the db (and added the 2011 cert to dbx with the updated bootmgr).
I know it's the norm to bash Microsoft and they do a lot of crappy things, but in this case it was just certain distros not taking security updates seriously, which is why a lot never broke (such as Fedora)
There was some systemd work on a spec for a boot partition to extend the efi partition for storing kernel images and initramfs, but I don't think any distro currently defaults to it on.
I think hibernation is currently also broken, since the hibernation file is stored unencrypted by default and thus can't be used with secure boot.