But it was certainly possible for a Linux vendor to have got a key into the kek and dB lists: https://mjg59.dreamwidth.org/12368.html
That's from Matthew Garrett, who along with Peter Jones, were responsible for the first shim.
A central authority like the Linux foundation could have stepped up here and could have since, actually. I understand why fedora/redhat preferred not to be in a privileged position but I can't help but feel someone ought to have stepped up.
The other side of the coin is the windows logo program, that requires secure boot be turned on by default. For x86 I'm fairly sure it also requires that the user can take control of the platform key and therefore evict Microsoft keys from the firmware. It also requires that secure boot should be disabled. I'm fairly sure Microsoft did this because they realised there would be objections otherwise
Microsoft's ARM hardware _is_ locked down with no such options and I object to that wholeheartedly. But then I also don't buy Apple kit for daily driver use for the same reason. Also luckily Microsoft are currently irrelevant in the arm space, although that might change with the serverready profiles.
I am sure the process was onerous, but someone could have done it. Linux is big business in the server hardware space and intel for example contributed the thunderbolt code to the kernel. I am fairly sure they could between them organise a foundation and throw a few 100ks per year at maintaining a signing key for other distros independently to Microsoft.
I don't believe any entirely locked down firmware ever made it into any x86 board.
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.
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.
I don't understand your second part though. What is the "step up" available to Linux vendors that they didn't do?
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.
There are some Android x86 devices that won't boot unsigned firmware and won't let you change the signing keys. But I've only seen that in non-BIOS, non-UEFI devices.
Your text is written in past tense. But if there is a maintained list why is nobody working to get linux vendor keys in now? Yeah, it'll take a while for the hardware cycle to refresh, but it's better than nothing.
The status quo was that systems could boot any operating system the user wanted. Microsoft tried to force OEMs to lock operating systems other than those on a very short list (they tried to force Secure Boot to be enabled with no way for users to turn it off, and you can confirm this by checking out earlier versions of the UEFI spec), knowing very well that that list would always include Windows for pretty much every computer out there, but you try to spin this as it somehow being every other vendor's fault for not getting in on that list with each and every manufacturer?