Shared publicly  - 
Microsoft wrote an article about how they weren't making it harder to install Linux which described, in detail, how they're making it harder to install Linux. Here's my response.
Alon Lischinsky's profile photoKim Halavakoski's profile photoRoger Jørgensen (dJeimsb)'s profile photoJes Sorensen's profile photo
time for redhat, canonical and other linux vendors to team up and take legal actions?
I agree, just read the MSDN article and it seems to be deliberately misleading. It should state unequivocally that "End users will be able to run whatever OS they want" or similar.

Surely secure boot is anti-competitive, whether it's Microsoft or the OEM's who are stopping you from installing another boot loader or disabling secure boot altogether.
I wonder if graphic card manufacturers like Nvidia, AMD and the rest have expressed public concern about the potential misuse of UEFI to make hardware updates more troublesome for the users...
+Mathias Hasselmann: i think HW-Vendor for Graphics, Storage-Controller and Network would have a much bigger impact in contrast to our vocal minority, like +Albert Vilella said. Problem: they live from OEM sales and would shut up if their key is included...
On the contrary, I don't see it as Microsoft's job to specify the requirements for other OS'. They've provided their requirements, Linux vendors should make clear to ODMs and OEMs the requirement to disable secure boot (and/or provide user keys). Where is the Linux 2012 hardware spec? We're not talking about small rag-tag groups anymore, Linux is backed by billion dollar corporations. Act like it.
I agree with Mace. Linux as a whole needs a quick and convincing response to this. There needs to be an easy way for OEMs to support secure booting of both Windows and Linux. This may require some software that is not covered by GPLv3. In order to protect the integrity of the rest of the GPL infrastructure we may need some intelligent compromises. In the short run I'm wiling to disable secure boot, assuming OEMs allow it. But that's not a good solution. And a good solution is likely to require cooperative work with BIOS vendors (who I assume will be doing this) before the first large-scale deployment of this.
+John Peter Lewis Secure boot is not, in and of itself, anti-competitive. If the end user controls which keys are accepted, it's fine; if I want to run something new, I change the keys in the hardware. If the hardware vendor controls which keys are accepted, it's anti-competitive, as the vendor chooses what software I'm allowed to run.
Sad, in that what could get lost in the noise is that secure booting is actually a GOOD idea ... as long as appropriate freedom and control is left in the hands of the owners (aka the people who spent the $$ on the PC, and deserve to use it how they see fit). It's just so rife with opportunities for abuse, like the above, by anyone who doesn't agree that I actually OWN my PC, that thinks they somehow have rights wrt/ my PC that I don't.
+Simon Farnsworth If anyone can add keys to it, it kind of defeats the purpose a small bit. Anti-competitive in the way it could (and probably will) be used, since Microsoft have so far refused to flat out say that OEM's won't be able to remove the option to disable secure boot, let alone give assurances that any of the current boot loaders will be certified.
All that can be said about the capabilities of the technology is one thing, and what will end up happening is another. It's so tempting for any company to use a technology as a competitive advantage to put pressure on other companies that, at some level, it will end up happening. Even rather big companies like Intel, Nvidia or AMD will have to negotiate their way through the process, because they are not in full control, and smaller companies won't have much room for negotiation against big ones.
+John Peter Lewis I didn't say anyone could add keys to it - for a sensible setup, look at Google's ChromeBooks. There's a physical switch you must flick in order to bypass the secure boot process.

In much the same way, a UEFI secure boot world could require you to make a physical change to add a key to the secure boot process; this blocks malware from tampering with the boot path behind the user's back (claimed by Microsoft as the reason to do this), but doesn't have competition implications, as I can always unscrew the magic flap on the laptop and hold the button down.

I agree, however, that the likely implementation is going to be anti-competitive.
Maybe it's time for the Linux Foundation (or the Linux Mark Institute iirc) to have a "Linux Logo Program for Hardware". No disabling of UEFI secure boot, buggy ACPI, closed source requirements, or whatever -> no cute Linux Penguin Logo for you.
Couple of things. 1) The ideal scenario allows the user to hit a physical switch of some kind, which then allows the user to modify the list of trusted keys. This would allow secure booting of arbitrary code, including self-signed code. 2) While linux vendors may have some say for servers and workstations, the OEM hardware vendors have little-to-no reason to support key replacement on phones, tablets, consumer PCs, etc. Is it so hard to imaging Dell locking down your netbook like most phones already are?
+Simon Farnsworth I didn't say that you said that. I suggested that being able to add keys willy nilly would defeat the point.

I don't know if there is a sensible setup, since bypassing it means it's as good as not there anyway. What's stopping some malware disabling it and then running amok?

I am aware of the basic premises of the technology thank you.

The fact is it is simply a bad idea because you are relying on the big bad corporations being nanny and gatekeeper for you, and we all know how much they suck balls at that. End of as far as I'm concerned.
+John Peter Lewis I have yet to encounter malware capable of physically holding down a button that's hidden behind a screwed-on flap in order to bypass the security process without the end-user being made aware that something very strange is happening.

An amendment to the logo guidelines that would not involve the big corporations being nanny and gatekeeper is simple to imagine:

* Logo certified machines will provide a mechanism that a user with physical access to the machine to add or remove keys.
* Machines must ensure that this mechanism cannot be controlled by software.
* Machines must make the risk of security breach by using this mechanism clear to the person operating the machine.
* Machines must warn the end user that removal of Microsoft's key will render Windows 8 inoperative.
* Machines must provide a mechanism to remove all keys.
* Machines must provide a separate mechanism to add just the keys that were supplied with the machine.

The hardware required to comply with these requirements is trivial - one switch to enter key management mode that also affects the write-enable line to the key storage device. It does not weaken the system with respect to the stated threat model from Microsoft.

And the fact that I can describe this in under a minute, and could justify it to a non-technical regulator using Microsoft's threat model as laid out in the MSDN article, means that if Microsoft claim that this is an unacceptably weak mechanism, they have to justify that claim to the regulator.

Remember, Microsoft have a convincing non-technical justification for why secure boot is good for end-users; if we are to defeat the anti-competitive advantage they get from it, we need to demonstrate to regulators that there are ways to get the claimed advantages of secure boot without the "accidental" anti-competitive gain.
+Simon Farnsworth so you don't think it's possible malware could "fake" the button? I do. If it becomes popular enough, give it a few years, and we'll see.

To me this is analogous to people's freedoms being taken away to fight crime/terrorism. Back in the day if something like this was going to impinge on people's lives then it wasn't done. It's the way it should be now, too much freedom and privacy taken away. A general trend I think. This is too open to abuse.

Anyway I digress, we're just going to have to agree to disagree on this one, all the best.
In fact, sorry to double post on this, but the whole idea is fundamentally flawed.

Instead of farting around with all this certificate fluff make the BIOS/EFI, mbr and boot loader area read-only unless you press the "red" button that says "do not press".

The only possible reason for wanting to introduce certificates, companies "working" together on it read: colluding, is to otherwise monetize or extract every red cent from the proposition.
+John Peter Lewis If designed properly, malware could not fake the button.

Design it as a physical DPDT switch (like the RF kill switch on the side of my Dell laptop, which is similarly safe against malware).

With the switch in the safe position, one pole of the switch connects the key store write enable line to a suitable fixed signal level (either ground or Vcc as appropriate, the other pole connects a GPIO to ground.

With the switch in the "update keys" position, one pole connects the GPIO mentioned before to Vcc, the other pole connects the key store write enable to a second GPIO.

When the position indication GPIO is grounded, the UEFI refuses to enter key update mode. Malware could, in theory, fake this, and get UEFI into key update mode; it would then be unable to write to the key storage, as it cannot switch the write enable line to "enabled" - it's being held at "disabled" by the switch. A sophisticated version of this could detect the failure to write, and tell the user to go to the manufacturer for help (either the switch or key store has failed, or there is malware in the chain).

And the advantage of this over locking the MBR and boot loader against writes is obvious - if I have a bug anywhere in my boot loader that renders it insecure, I can fix it without training my users to bypass the security method. If I locked the MBR and boot loader, my users could be manipulated by malware into unlocking it in exactly the same way as I do for a genuine security update.
+John Peter Lewis What's so annoying about all this is that we play into their hands - by declaring it unworkable, we make it possible for those who'd take our computing freedoms away from us to say "they're just being recalcitrant - heck, maybe they're pro-malware".

By suggesting changes that meet their stated goals, knowing that they will not make these changes because it would stop them meeting their hidden agenda, we make it clear that they have a hidden agenda, and that they do not want to meet their stated goals unless they are also permitted to meet their hidden agenda. Oh, and it allows us to suggest that they are pro-malware...
Don't know, I am taking a very zero tolerance approach with this, more FSF than OSI. No no no no no! They're getting more and more desperate to strangle the competition, only delaying/bringing on the inevitable. The sooner the better AFAIAC. :)
+Christian Smith I'm not saying that people shouldn't speak out; I personally have written to my local authorities pointing out the flaws in the scheme as suggested, complete with my tweaks that make it work for me.

I am saying that Microsoft have a convincing-sounding case for why this is the best way to stop malware. We need to make clear that they're hiding an anti-competitive weapon in there, and that they don't need to do so.

Put simply, if you say "this scheme bad!", the response is "malware also bad - why you not want malware problem solved?" If you say "this scheme needs user control of keys, otherwise anti-competition", Microsoft has a hard time explaining to a worried regulator just why they can't allow that.
Add a comment...