Its like selinux hardware edition.
This isn't a thing on the stock kernel.
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.
There are however going to be a lot more issues self-enrolling keys going forward.
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.
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.
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.