From this I get that "BIOS compatibility mode" is a required specification. Then I can ignore all the rest of the article.
I have recently been learning about OpenBSD. I really like how they have handled all the weirdness associated with PC architecture booting/partitioning. OpenBSD simply ignores it and does everything on top of it. Once you have a partition marked as OpenBSD you are done the architecture specific stuff. Then you go on to do things the OpenBSD way which is the same over all architectures. So when Intel comes up with UUEFI (or whatever) you can continue to ignore the whole mess.
Compatibility Support Modules ("BIOS compatibility mode") aren't required. The text states "many UEFI firmwares implement some kind of BIOS compatibility mode, sometimes referred to as a CSM.".
"many" not "all", and the article sticks to that.
Since CSMs are incompatible with Secure Boot (since they can run whatever, without extending the trust chain), I expect them to be on the way out.
Same as with the "Secure Boot optional" requirement on x86, by the way, since I guess that the real reason Microsoft added that to their Windows Logo requirements is that their large customers wanted to be sure that they can image Windows 7 onto new machines for a while longer.
Once this kind of legacy is gone for good, Microsoft may tighten the screws there. And since all big Linux vendors support Secure Boot now, that part of the PC landscape won't make many noises either.
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:
I very much doubt that just marking a partition as OpenBSD is the end of the architecture specific stuff. Somehow the firmware in your computer has to actually boot the OS. Unless things are setup in a way which is acceptable to the firmware with regards to booting (be it mandatory filesystems, directory structure and file formats, master boot records, partition table entries and corresponding flags, GUIDs, bootsectors, etc.), nothing much is going to happen when actually trying to boot it.
Really. Once the OpenBSD partition boot sector gets control everything is done the OpenBSD way. There is some compatibility stuff for PC type partitions but it does not affect normal operation in any way. The GUIDs are the OpenBSD GUIDs. You don't even need a GPT for disks larger than 2GB because the OpenBSD stuff works up to 64PB.
I have recently been learning about OpenBSD. I really like how they have handled all the weirdness associated with PC architecture booting/partitioning. OpenBSD simply ignores it and does everything on top of it. Once you have a partition marked as OpenBSD you are done the architecture specific stuff. Then you go on to do things the OpenBSD way which is the same over all architectures. So when Intel comes up with UUEFI (or whatever) you can continue to ignore the whole mess.