[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.