[AshamedCaptain]

They also do this because it is likely that Microsoft will stop signing their bootloaders/kernels with their UEFI CA keys if they allow arbitrary user modules to be loaded (because it would be trivial to abuse those kernels to break Windows' full disk encryption).

And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup.

[jeroenhd]

Secure boot allows you to load your own keys. That's the way some Linux distros actually recommend you to set it up: sign your own bootloader, kernel, kernel modules, everything, and tell your motherboard to trust that. It's arguably even more secure than Microsoft's approach because anyone can boot a Windows install disk, but getting a boot drive with your signature on it requires breaking into your system. This could be a little challenging if you try to update firmware through manufacturer supplied boot images that expects their Microsoft signature to work, but it's not impossible to work around that.

For dual booting you'd need to load both sets of keys (your own and Microsoft's) or configure your primary bootloader to trust Microsoft's signature and chainload.

There's nothing inherently Microsoft related about secure boot, except for that on some Microsoft devices where the ability to use your own keys has been taken away from you. Don't buy a Microsoft Surface without checking its Linux limitations, basically, but that's a Microsoft problem, not a secure boot problem.

If you don't like being restricted, just turn off secure boot. Or turn off any verification that happens after secure boot; it's the Linux kernel that's enforcing drivers it loads to be signed, not the secure boot standard. Patch out the verification routine with a return true if you have to.

Everything will boot and load, which may or may not be a good thing, depending on your requirements.

[bitwize]

> There's nothing inherently Microsoft related about secure boot,

Microsoft is the root of trust for ~100% of OEM secure boot implementations.

Theoretically, you can implement Secure Boot with an alternative root of trust... but you'd have to get the OEMs on board... to the tune of many millions of dollars. Per OEM.

The only alternative is to get users to install their own keys, which is fiddly and technical.

Therefore, for all intents and purposes, Linux on the desktop is only a thing at all because Microsoft deigns to allow it for the time being.

[bscphil]

> The only alternative is to get users to install their own keys, which is fiddly and technical.

It's a bit worse than that actually; it's actively scary and dangerous, as with much EFI stuff. Quoting the Arch Wiki:

> Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft's key.

The key process creation itself is extremely manual and finicky, and probably prone to error.

The process of enrolling your platform key involves deleting all enrolled certificates. Let's hope your hardware provider implemented this properly so you didn't just brick your system.

> Once Secure Boot is in "User Mode" keys can only be updated by signing the update (using sign-efi-sig-list) with a higher level key. Platform key can be signed by itself.

So any loss of your platform key (e.g. by cosmic ray flipped bit, or hard drive failure, or simply user error) results in effectively bricking your hardware, right? (Unless and until you can rewrite the firmware with a hardware device.)

I'm sure some folks have worked out a good process for managing all this, but it feels so flaky to me and I don't have a good handle on what is required to do this right. Back in the day, installing Linux for me used to involve 2-3 cycles of screwing up something with GRUB, having to boot into the LiveCD, and fixing things. Right now it feels like one screw up could be fatal to hundreds of dollars of hardware. That's before you get to the issue of having to mess with the EFI variables, which has resulting in bricking hardware in the past: https://www.theregister.com/2016/02/02/delete_efivars_linux/

Again, some of the above could be based on my misunderstandings, but that's kind of the point as well - the scary thing about secure boot / UEFI for Linux users is that it's a new area of required knowledge that you seemingly need to be 100% right about or risk burning hardware.

[Foxboron]

I wrote sbctl to try and make sure self-enrolling keys is completely painless

https://github.com/Foxboron/sbctl

[AshamedCaptain]

I am not saying that you can't fiddle with the BIOS (and or preloader or shim) to workaround this; I'm just saying that this is the MS-signed distro's motivation to lockdown bootloaders and kernels when you are booting with SecureBoot on.

[Foxboron]

>And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup.

Not really?

Several popular Linux distributions simply do not support Secure Boot. Arch Linux is one of them.

[tremon]

That's because current generation of hardware does not mandate secure boot on x86. I expect that will change once Windows 11 has had a few years to turn the majority of the computers secure-boot capable due to its hardware demands.

[Foxboron]

That would be against the current UEFI spec. I get that people are cynical and expect this to happen but I don't think it will.

There are however going to be a lot more issues self-enrolling keys going forward.

[bscphil]

Just for clarification, I believe you mean that it's not something supported out of the box, in the form of a signed kernel / bootloader. It is something Arch Linux users could choose to set up themselves; there's a whole wiki article on it.