> Microsoft's ARM hardware _is_ locked down with no such options
That was for 32-bit Windows on Arm hardware. 64-bit Windows on Arm laptops/tablets have unlockable Secure Boot, with a regular SETUP interface and all.
All this does make Microsoft sound very reasonable, actually. People have been painting dystopian pictures of an ultra-locked down hardware future, complete with evil corporate overlordship etc for many years. Really as long as I've been using computers. Yet, here we are in 2021 and not only old hardware is still open but newly designed hardware too, and Microsoft has even been ensuring that platforms which didn't get the memo (mobile, ARM) open up.
The problem with a completely unlocked bootloader is that the distinction between "a Linux distribution" and "malware" is not one that can be decided technologically. Otherwise malware could just install a heavily customized Linux kernel that directly boots into Windows, hot-patching it along the way, and who is to say it's not really Linux? Someone has to make that call for the ordinary userbase that doesn't care about operating systems and it sounds like out of an ideological fit of pique - what a surprise - Linux vendors just noped out and refused to do their part. Because, you know, malware is other people's problem. So now Microsoft finds themselves carrying water for their own competitor.
Given Microsoft's losses with eg Windows mobile, their late entry into the cloud space, giving up on making their own web browser (engine), Microsoft's forced to play nice in order to compete.
I don't understand your second part though. What is the "step up" available to Linux vendors that they didn't do?
I feel maybe I should elaborate on this more because a lot of people in this thread don't seem to quite understand the UEFI thing. Yet I cannot see an error or oversight in the chain of logic, so Linux vendors really deliberately screwed themselves over here and it's quite impressive actually that Microsoft bailed them out.
1. Computer makers want to sell computers to the masses. This is reasonable.
2. The masses don't want un-removable malware that renders their virus scanners useless. Also reasonable.
3. Malware writers want to beat virus scanners by taking over the OS before it even boots, which is an unassailable position for them. This is "reasonable" from their POV. Likewise, computer makers - not just Microsoft - want to stop this from happening because it's a kinda game over move and there's nothing that really prevents it (pre UEFI) other than the fact that the programming is kind of tricky.
4. To fix this the computer maker must have some opinion about what the computer is willing to boot. Boot-loading code is henceforth separated into "good" code that makes users happy by letting them surf the web, print etc and "bad" code that makes users unhappy by screwing with their machine and data and possibly bank accounts. This appears to be unavoidable and can be implemented with cryptography.
5. But computer makers don't really want to have such an opinion because it's a live wire for geeks who run obscure operating systems. They just want to get rid of malware. So they need a default, reasonable whitelist that will make users happy, and then a way to edit that whitelist that is too difficult for users to get phished or scammed into doing by accident. Whitelisting public keys in the UEFI/BIOS screen seems like a reasonable approach to this.
6. To have a signing key that's shipped out of the box you must agree to some simple rules, like, you must actually not be malware, and you must not accidentally sign malware, and you must protect your key, and you must not sign a piece of software so open that it can be trivially wrapped around malware. The first three are easy but the sorts of guarantees best made by an institution, not an individual. Microsoft is an institution. "Linux hackers" are not. But, there is a Linux Foundation that could play the role and helpfully already own the Linux trademark (I think), so they already kinda get to decide what is and isn't really Linux.
7. The final condition is the harder one because it implies a chain of trust. Otherwise the malware writer can just create a bespoke Linux that boots into a minimalist Linux environment and then immediately unloads Linux and chains onwards to a patched Windows. So each whitelisted Linux distro needs to have a default opinion about what can run in kernel mode that is (again) overridable, but only by people who know what they're doing. Which Linux can do, via module signing. So no technical problem here.
8. At this point Linux vendors appear to have flounced out of the room and collectively decided they can tell the PC industry what to do by refusing to take part in the process. They were wrong, nobody gives a shit about desktop Linux because it has hardly any users. However they only realized this way too late, by which time PCs were already shipping without any Linux Foundation keys in the whitelist. What to do?
9. Answer: go crying to your primary competitor and pressure them/ask them nicely to fix your fuckup by using their own cert to sign your operating systems.
This is kind of pathetic and it appears the Linux community has still never got its act together and set up a key whitelisting process.
Take part in the UEFI secure boot process to get a key whitelisted that'd be shipped in hardware out of the box (e.g. one managed by the Linux Foundation).
That was for 32-bit Windows on Arm hardware. 64-bit Windows on Arm laptops/tablets have unlockable Secure Boot, with a regular SETUP interface and all.