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:
"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.