Last I remember the Linux distros were just using a shim to get around the secure boot stuff. In other words, something that just boots from the partition that Linux just happens to be in with no verification of what that is. If things are to be tightened then the keys for the shim would have to be revoked. Then everyone is sad. Otherwise the OpenBSD approach still works as normal with the shim.
The shim loader is an MIT-licensed piece of code that's signed by a Secure Boot CA, typically MS for off-the-shelf x86 hardware. The shim has another public key hard-coded into it, and verifies that the next bootloader (usually GRUB 2) is signed with that key. It works around a couple of issues:
- The turnaround time for getting something signed by MS is slow. Linux distros want to be able to push out a new version of GRUB on their own. So by having the CA sign a shim loader, new versions of the boot loader can be signed with the distro's key alone, which they can automate as much as they want.
- There's some ambiguity over the GPLv3's TiVoization clause, so to avoid any interpretation that MS would have to hand over its own private key, MS won't sign any GPLv3 software directly (like GRUB). The distros think this is a non-issue, and they're happy to sign their own GRUB binaries without imagining they'd have to give up their private keys.
It doesn't change the security model of Secure Boot at all. You're still verifying that someone whose key is in hardware has a trust path to your bootloader. It's just that the trust path is one more step away.
If you want to include your distro's key in the UEFI variable that lists your Secure Boot CA roots, you can do that, and skip the shim. (You probably can't remove MS's key because UEFI drivers are signed with it, but that's a different issue.)
Some distros (notably Ubuntu) have their bootloader willing to boot unsigned kernels, on the grounds that Secure Boot protects UEFI "boot services" (things that run while UEFI still controls the machine, including access to certain UEFI variables like Secure Boot config), but does not protect ring 0. Other distros (Fedora, SuSE, etc.) think that that's nonsense, and Secure Boot obviously protects ring 0. So their bootloader only boots signed kernels, and those kernels, in turn, only load signed kernel modules.
MS has complained about Ubuntu's interpretation, but has so far not shown any signs of forcing Ubuntu to change their practices. (I suspect with no real information that MS is worried that, if they're holding the only CA for PC hardware and they revoke the most popular Linux distro, they're going to be reminded of what antitrust lawsuits feel like.) You can see MS's signing policy here, including a link to the (non-MS) shim:
