Unfortunately, people in the real world use implementations of secure boot, not its specification.
>If you want to get cheap volume licenses of Windows from Microsoft to pre-install on your computers and have a nice “reassuring” ‘Microsoft Approved!’ sticker or whatever on the case, you have to comply with these requirements. That’s all the force they have.
Post-US vs. Microsoft, MS does not want to be seen to be explicitly violating anti-trust law, which is why in public and on the record, they will say and do nothing wrong. This has actually done a lot of good, because it does shackle their ability to engage in anti-competitive behavior.
It just doesn't shackle it completely, and it means that in order to do it they have to be a bit more creative.
They still wield a large amount of power over the PC market, and manufacturers know this. They still have several ways of opaquely favoring or disfavoring some manufacturers over others. Manufacturers, on the whole, dont't mind being opaquely favored and don't want to be opaquely disfavored and know that crying foul about Microsoft abusing its market power in secret won't do them any favors either.
It's a cut throat market and nobody is going to feel sorry for you as a manufacturer if you died out because you didn't get an Microsoft promotional tie in.
Thus sometimes, all it takes for anti-trust violations to continue and to go unpunished is a nudge and a wink or an off the record conversation between MS and manufacturers, and a decision made by either party that falls in a gray area of legal defensibility.
Here's where it gets evil, and here's the bit you are glossing over:
Secure boot PROVIDES that gray area while maintaining a veneer of respectability.
>If you have an x86 system that claims to be Windows certified but does not allow you to disable Secure Boot, it is in direct violation of the certification requirements, and you should certainly complain very loudly to someone. If a lot of these systems exist then we clearly have a problem and it might be time for that giant lawsuit, but so far I’m not aware of this being the case. All the x86-based, Windows-certified systems I’ve seen have had the ‘disable Secure Boot’ option in their firmwares.
Certainly you seem to be able to turn it off in most implementations I've seen, but I haven't seen any that let me add trusted keys myself. Another gray area methinks.
Nor is turning it off particularly easy. I know where it is and what it does, but I know the history behind it.
MOST people draw a blank stare when they look at it and CERTAINLY don't get to the menu and look at it and think "oh, for sure this is the thing that stops me from installing linux".
Oh, and incidentally I've never eer seen a coherent error message caused by secure boot's "protection". Not "you appear to be installing an untrusted OS". Just blank screens and opaque error messages.
Let's say hypothetically that instead of being buried three menus deep, it was a physical switch, with a clear explanation about what it actually does.
Let's say hypothetically that adding a key for secure boot were done using a clean and simple UI that my mother could follow. Flip the switch, plug in a USB key to boot from, menu asks if you want to trust this OS. You say yes and flip the switch back on.
Let's say hypothetically that trying to install an "untrusted" OS gave you a clear error message.
If these were the case (and these things certainly adhere to the spec), I wouldn't have a problem with it either. Let's be realistic, though. It's not that. It was not ever intended to be that. It was not supposed to be used to secure your system, and while Microsoft did just enough to avoid a lawsuit over it, their intentions are crystal clear.
Hardware manufacturers also know what's up, and won't be making it an easy to use feature any time soon.
MS is playing the same game they did pre-DOJ, they're just trying to keep plausible deniability at the same time as greasing all of the right palms. MS pretends not to violate antitrust law. Microsoft contributes to all the right election campaigns. DOJ pretends not to notice that Microsoft's secure boot initiative (if not the spec) is anti-competitive.
>As far as x86 devices go, though, right now, Microsoft’s certification requirements actually explicitly protect your right to determine what can boot on your system. This is good.
Microsoft is not explicitly breaking the law here. This is indeed good. Let's award them a fucking medal. By the way, I didn't deal drugs today. This is also good.
As for UEFI itself - it reminds me of XML - designed by committee, and yes, strictly speaking it does do the job, but it's ridiculously overcomplicated and the market is littered with terrible implementations because of that complexity. Worst of all it was never truly necessary because a simpler specification (where's the UEFI equivalent of JSON?!) would have sufficed for all use cases.
Another thing reminds me of XML too. There was a good market in being an expert in XML for a while. It was almost a club, in fact. The arcaneness plus the reliance the world had on it made for some excellent opportunities. Opportunities that, say, JSON never provided.
There appears to be a good market to being the go to guy for UEFI too.
Just sayin'