5 ms·

>Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – b

>Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – but about specific implementations of Secure Boot in the real world. 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'

erglkjahlkh 12y ago
The problem with secure boot is that most want to choose what parties to trust for managing the security of the boot chain. Microsoft is not on the list of many, and many large corporations and such would want to certify the sources themselves with more granularity. Whether this is a perceived or a real problem, I can not say, but until it is corrected this will slow the adoption of these new features.
- crdoconnor 12y ago
  >The problem with secure boot is that most want to choose what parties to trust for managing the security of the boot chain. The problem is that this process of whom to choose is completely opaque and usually based upon who has the most market power, definitely not who is the most trustworthy. Hence tons of OEMs ship with Microsoft's key being the only trusted one. Imagine if the only CA trusted in 95% of browsers was Microsoft's CA. We'd be seeing blog posts like this telling us that since we didn't read the SSL spec, and because it's open, we're all just a bunch of know-nothing whingers :)
  - adambatkin 12y ago
    What other keys should they pre-install? Let's face it, most motherboards will run Windows, so it makes sense to ship Microsoft's keys (also they have to do that to get certified by Windows). Do you really expect OEMs to go hunting down keys from Red Hat, SuSE and Canonical? What about all the other little distros? I would expect that companies like Microsoft know how to handle key material properly (plus they have a vested interest in doing it correctly), but how much do you trust all the little distros? Once a key is trusted, it's trusted, so if you want Secure Boot to do-what-it-says-on-the-tin, you need to have confidence that the pre-installed keys are all kosher. And the CA model will definitely not work - we have seen what happens in the browser world. One bad CA, one bad signed certificate and the game is lost. And since it's running in firmware, there's no easy way to revoke or blacklist certificates. I run Linux exclusively on my PC (and have for 15 years) so I'm sympathetic with everyone's concerns with Secure Boot, but I also completely understand why only Microsoft's key is pre-installed on most systems, and I believe that's probably the correct solution. The fact that the UIs for installing new keys or disabling Secure Boot suck is a good point. Complaining that Microsoft's key being the only pre-installed key isn't.

erglkjahlkh 12y ago

The problem with secure boot is that most want to choose what parties to trust for managing the security of the boot chain. Microsoft is not on the list of many, and many large corporations and such would want to certify the sources themselves with more granularity. Whether this is a perceived or a real problem, I can not say, but until it is corrected this will slow the adoption of these new features.

crdoconnor 12y ago
>The problem with secure boot is that most want to choose what parties to trust for managing the security of the boot chain. The problem is that this process of whom to choose is completely opaque and usually based upon who has the most market power, definitely not who is the most trustworthy. Hence tons of OEMs ship with Microsoft's key being the only trusted one. Imagine if the only CA trusted in 95% of browsers was Microsoft's CA. We'd be seeing blog posts like this telling us that since we didn't read the SSL spec, and because it's open, we're all just a bunch of know-nothing whingers :)
- adambatkin 12y ago
  What other keys should they pre-install? Let's face it, most motherboards will run Windows, so it makes sense to ship Microsoft's keys (also they have to do that to get certified by Windows). Do you really expect OEMs to go hunting down keys from Red Hat, SuSE and Canonical? What about all the other little distros? I would expect that companies like Microsoft know how to handle key material properly (plus they have a vested interest in doing it correctly), but how much do you trust all the little distros? Once a key is trusted, it's trusted, so if you want Secure Boot to do-what-it-says-on-the-tin, you need to have confidence that the pre-installed keys are all kosher. And the CA model will definitely not work - we have seen what happens in the browser world. One bad CA, one bad signed certificate and the game is lost. And since it's running in firmware, there's no easy way to revoke or blacklist certificates. I run Linux exclusively on my PC (and have for 15 years) so I'm sympathetic with everyone's concerns with Secure Boot, but I also completely understand why only Microsoft's key is pre-installed on most systems, and I believe that's probably the correct solution. The fact that the UIs for installing new keys or disabling Secure Boot suck is a good point. Complaining that Microsoft's key being the only pre-installed key isn't.