OpenBSD's De Raadt Slams Red Hat, Canonical Over 'Secure' Boot

An anonymous reader writes "OpenBSD founder Theo de Raadt has slammed Red Hat and Canonical for the way they have reacted to Microsoft's introduction of 'secure' boot along with Windows 8, describing both companies as wanting to be the new Microsoft."

Comments

A bit over the top

[jmorris42]

We have been hearing various people who should know better that "Redhat is the next MIcrosoft" and variations on that theme now for at least a decade. Guess Ubuntu should take it as a sign that they have 'made it' that the same is now being said of them.

Not saying I agree with either of their solution to the Kobayashi Maru (otherwise known as Secure Boot) problem, but calling them 'traitors' is a bit much. Especially since I can't rightly say I have a better plan and neither does Mr. deRaadt.

Re:A bit over the top

[Hatta]

Especially since I can't rightly say I have a better plan and neither does Mr. deRaadt.

The better plan is to sue Microsoft for abuse of their monopoly.

Re:A bit over the top

[jmorris42]

> The better plan is to sue Microsoft for abuse of their monopoly.

The old consent decree is long since expired. Good luck starting up a new round of lawsuits, Microsoft discovered lobbists after the last round so the DOJ isn't going to be bothering them again. So your plan is do nothing for years while a court case winds its way through the system and more then likely ends up going nowhere. Boy I'd love to take that plan to the stockholders meeting.

Re:A bit over the top

[AdamWill]

"Requiring other OS makers to buy a license from Microsoft is very clear evidence of using their monopoly power to stifle competition"

It certainly would be. The only problem is that they're not doing that at all.

The industry as a whole agreed to ratify the basic Secure Boot mechanism as part of the UEFI standard. Secure Boot as described in the UEFI standard does not say anything at all about who should sign code and issue keys and any of that stuff. All it does is say 'here is a mechanism called Secure Boot by which the system firmware can maintain a list of keys and refuse to run code which is not signed by one of those keys'.

So once that's in the UEFI standard, we have a world where there is this thing called Secure Boot which operating system developers and hardware vendors can *choose* to implement. Or not. The UEFI standard says nothing about whether it ought to be used, what keys ought to be included, or anything like that.

So Microsoft, as an operating system vendor, decides they want to use this Secure Boot thing. They're going to sign their operating system, and require vendors who want to pre-load that operating system on their systems to ship Microsoft's key. So that their operating system will run. This is what the Microsoft Windows 8 certification requirements for x86 state: you have to turn Secure Boot on by default and include our key.

What the certification requirements explicitly do _not_ state is this: 'you can't include any other keys'. They definitely don't say that. They just say 'you have to include Microsoft's key'. There's no restriction at all on shipping any number of other keys. Additionally, the certification requirements explicitly require that the user be able to enrol their own keys, and also disable Secure Boot if they so desire.

So...Microsoft's requirements for OEMs are that they enable Secure Boot by default (but allow it to be disabled) and ship Microsoft's key (but they can also happily ship any number of other keys, if they choose).

It's logically impossible to construe this as "Requiring other OS makers to buy a license from Microsoft". It doesn't do that, at all. Other OS makers can have their OS signed by themselves or anyone else they like, and ask hardware manufacturers to ship that key. Microsoft does nothing to prevent this. Or they can choose not to sign their OS at all, and ask users to disable Secure Boot. Microsoft does nothing to prevent this. Or they can _choose_ to have Microsoft sign their OS so it'll work without them needing to get any other key loaded into firmware; Microsoft didn't _have_ to provide public signing services, but they are doing so to avoid a PR shitstorm. If Microsoft really wanted to be evil, why would it provide public signing services at all? Wouldn't it be more effective just to say 'no, we won't do that'?

I find it highly unlikely that you could build a convincing case of monopoly abuse over Secure Boot for x86, when the actual facts of the matter are taken into account. They just don't support the accusation strongly enough. If Microsoft could be shown to be exerting pressure to prevent alternative signing groups from existing or getting their keys loaded onto hardware, then maybe...but AFAIK no-one has shown such.

(disclaimers: I am not a lawyer and this is not legal advice or a legal opinion. Furthermore, though I work for Red Hat, I am not directly involved in any RH evaluation of this issue, I am not involved in RH legal in any way, and this is entirely a personal opinion and not in any way representative of Red Hat. It is not Red Hat's official position on the issue of the legality or otherwise of Microsoft's actions. I specifically leave open the possibility that Red Hat as an entity might take a completely opposite view of the case.)

Re:A bit over the top

[vux984]

), but it doesn't change the fact Canonical and Redhat were forced to buy a license *from Microsoft* or else their OSes would not run.

That is not true.

Their OSes will run just fine provided any of the following are done:

a) the user logs into UEFI and disables secure boot

b) the user logs into UEFI and installs a distro key

c) the user logs into UEFI and installs their own key and signs the distro themselves.

d) the distro provider works with the manufacturer to have their key pre-loaded the same as microsofts.

Microsoft (currently) does prevent or even hinder any one of those alternatives on x86.

Canonical and Red Hat noted that a & b require at least a nomimal effort by the end user. (c requires a fair bit of effort for the end user) And that d required a substantial effort on their part.

So they chose "e) sign our distros with the MS key" that Microsoft already took the effort to have preloaded so that our users don't need to take the nominal step of disabling secure boot or of installing their own keys.

"That is called restraint-of-trade and it is VERY clearly a violation of the Sherman Antitrust "...

No its not.

"now they are actively blocking other OSes from Opera/Google/other OSes from running (unless they beg MS for a license)"

You don't need a license from microsoft. The end user can disable secure boot. The end user can install their own keys. The distro can approach the hardware manufacturer and have their own keys preloaded along side microsofts.

Microsoft isn't preventing anyone from doing anything, and you do not need to interact with microsoft at all to install other OSes.

Please COMPREHEND the above before replying or commenting on the subject further.

Re:A bit over the top

[AdamWill]

"That's a nice 3-page essay (double-space I presume), but it doesn't change the fact Canonical and Redhat were forced to buy a license *from Microsoft* or else their OSes would not run."

That's still not a fact. We were not forced to buy a license. We had several options, which Matthew outlined way back at the start of this whole saga, in this blog post:

http://mjg59.dreamwidth.org/12368.html

Specifically, the paragraph headlined "Getting the machine booted". It mentions the other options, including "the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it" and "producing some sort of overall Linux key". There is also the obvious negative possibility of simply not signing anything at all; this would require users to disable Secure Boot in the firmware before installing Linux, but it doesn't prevent them from doing so.

Both Fedora (note, Fedora, not RH; RH does not necessarily always follow what Fedora does) and Ubuntu had several choices and _chose_ to go with the Microsoft signing service as the 'least bad' option (well, Ubuntu will also be self-signing, for OEM preloads). The fact that we are _choosing_ to get our releases signed with the Microsoft/Verisign key does not imply that we were _forced_ to do so. We _choose_ to do so on the basis that it'll provide the maximum possible success rate of Fedora installs with the minimum amount of work. We could have chosen to self-sign, or not to sign at all, and ask users to disable Secure Boot or import our key. We decided not to do so.

"Problem si that peope like YOU seem to think corproatuions never od anything wrong"

This is an absurd stretch. You appear to be implying that anyone who suggests that a corporation might ever do anything at all that is _not_ wrong, must therefore believe that a corporation can _never_ do anything wrong. This is clearly ridiculous and false. You also mistake my opinion that Microsoft's actions are _not illegal_ for an opinion that they're _right_. These are not the same thing at all. I have carefully refrained from stating in public any personal opinion on the Rightness or Wrongness, from an ethical/moral standpoint, of Microsoft's actions. This is intentional. What I have said several times is that I don't believe the actions can successfully be characterized as _illegal_. Not everything that's wrong is also illegal. But if something is wrong/bad but not illegal, then you can't defeat that something through the courts. This sub-thread was prompted by someone saying that RH and Canonical should have chosen to prosecute or sue Microsoft. My point is that this is hardly a viable option if the suit would fail.

Re:A bit over the top

[jonwil]

Microsoft may have discovered lobbyists but their lobbyists didn't save them from EU rulings (Windows N with no media player, the "Browser Choice" screen etc). There is no reason to think the EU wouldn't be interested in investigating other abuses of monopoly power by Microsoft (including anything to do with secure boot)

Like RMS, Theo De Raadt is right when everyone

[RLiegh]

else is wrong.

Sadly, MS has the power to take control of our computers away from us --and with secureboot they're doing exactly that. This is a direct attack on personal computing and the freedoms of the end-user to control the software on their computer.

RMS and Theo De Raadt are both right on this --but neither one of them has the influence needed to avert this attack, so it doesn't matter.

The era of personal, general-purpose computing is over.

Theo ranting, film at 11

[Anonymous Coward]

Theo, ranting, is why he got kicked off the NetBSD project. Theo, ranting, is why OpenBSD's drivers for Broadcom chipsets stink. (Look up how the original author tried to resolve the licensing problems of sticking his GPL drivers in an OpenBSD kernel and was ignored, then screamed at by Theo for making the issue public.) Theo, ranting, is why OpenBSD doesn't properly handle booting from software RAID. Theo, ranting, is why the OpenBSD installer works like the UNIX crap I learned to loath back in 1985 and can't store the state of what you've already selected or go back, you just have to start over from scratch. Theo, ranting, is why OpenSSH has no built-in support for chroot cages. Theo, ranting, is why OpenBSD has no virtualization server capability. Theo, ranting, is why OpenSSH still stores both host keys and by default, user private keys in clear text with no expiration, and has no plans to fix this. Theo, ranting, is why the "compatiblity chart" is a list of chipsets that don't match the actual chipsets published by the manufacturer, and usually are from chipsets at least 4 years old.

Theo, ranting, usually means you're doing something right for your actual client base rather than for his ivory tower. There's a reason OpenBSD is used only by fanboys who run it on "hobby" systems and don't get any work done. And yes, I've dealt with the crap for years: I *wrote* the first SunOS ports of SSH-1, SSH-2, and OpenSSH. (Theo's fan club did not write SSH: they ported Tatu's previously GPL work into OpenSSH, and screwed up the license. Surprisingly little of the actual codebase is due to OpenBSD hosted development.)