Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

[Thibault Nélis]

On 06/01/2012 09:46 AM, Alan Cox wrote:
> Out of support releases are also an interesting problem. If a hole is
> found they need to revoke the key. If they do that the users machine is
> crippled. It's potentially a criminal matter in many EU states as well so
> whoever issues the revocation could end up in jail. Nobody is really too
> sure. This is all untested waters.

If we're talking about the kernel, one can always make the boot loader 
prompt the user whether it wants to continue without the assurance of a 
safe boot, possibly launching the (unsafe) kernel in some sort of locked 
down mode (filtering connections and whatnot) to try to avoid compromise 
in case the system isn't yet infected.  All the system has to do is 
fetch a new kernel and install it somehow, and if it does, even if it 
*is* infected, it would work, since the bootloader is assumed to be secure.

If it's the bootloader that doesn't match, the shim could do the same.

The thing is, if machines are compromised, the first thing the malware 
will do will be to block the revocations coming from the network.  As 
such, I think that for real-world end-users who don't go fetch 
revocations frequently via secure back-channels, the only real advantage 
of secure boot will be to stop the spread of malware, not cure it.  For 
that, you would still need the usual detection and removal techniques.

Don't get me wrong, containing malware infections is still a huge win, 
especially when we consider the number of active botnets today, but to 
me I don't think OS developers should worry too much about locking down 
infected machines.  If it's infected, the fight is already lost.

Or I maybe I totally missed something;  is the firmware able to go fetch 
revocations itself?  Not sure I'd like that anyway.

> Correct - and you need to lock it down way more than that. Also I can't
> see Red Hat directly signing third party binary blobs. If it does that it
> implicitly believes they are lawful and also acquires some liability for
> them in they malfuction.

That's a good point, but a little disclaimer would do, wouldn't it?  I 
mean even today Red Hat shouldn't explicitly support them when it comes 
to security.  I hope they don't.

But you're right, it would seem weird to sign a blob and drop all 
responsibility for it at the same time.  I guess there's no use in 
secure boot if you execute software you don't trust anyway, so users of 
third-party binary blobs probably would naturally disable secure boot.

> It will be up to the Fedora Board to stop Red Hat corrupting the goals of
> the Fedora project in this way - or if they won't for people who dislike
> it to dump Fedora - particularly package maintainers.

That would be, well, extreme.  Say if legally OEMs are bound to empower 
the user to manage the keys in the firmware, would you still advocate 
against the use of the technology?

I mean, right now there's no real issue, OEMs will most certainly 
include *at least* the keys for the operating systems they pre-install, 
and that includes Red Hat (if not then there's something terribly wrong 
with the OEMs' common sense).  With a law that states that you must be 
able to manage your keys, I believe freedom is untouched.  I don't think 
any hardware vendor stated they would retract that freedom from users.

Now, users who buy machines with Windows pre-installed should expect 
their firmware to include Microsoft's key, and should be aware that they 
can add theirs legally.  If they don't want to use Windows and don't 
want the trouble of setting up keys they should either:

(a) Buy from an OEM which builds machines with their OS of choice 
pre-installed, including a secure boot key for it,

(b) Ask an OEM for a machine without any OS (if you install the OS 
yourself then you should be responsible for installing the key as well),

(c) Fight an OEM which pre-installs Windows to add a new key, possibly a 
set of keys from unbiased trust brokers that can distribute certificates 
(bootloader shims) to your OS of choice to make it more realistic.

Now that seems a little harsh for OEMs, but given Windows little 
monopoly*, I think everyone is OK with that - there is famously good 
precedent with users who got their money back on the license for the 
pre-installed Windows copies they got with their computers (even though 
their arguably knew that it was explicitly bundled as one product), so 
I'm pretty sure we'll make it work this time too since the situation is 
even more extreme.

* We can justify it by stating how hard solutions (a) and (b) actually 
are, but these kinds of OEMs do exist.  They're just too rare.
-- 
t