Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

[Thibault Nélis]

On 06/02/2012 01:26 AM, Sam Varshavchik wrote:
> [snip]
> I repeat: this is NOT going to happen. If you allow an open operating
> system to boot, as a trusted boot, then "trusted boot" ceases all
> meaning whatsoever for a non-free OS that requires a signed chain from
> the hardware. And I won't even start on the subject of virtualization,
> like KVM/Qemu/libvirt.

Well, *obviously*, nobody expects secure boot to do anything magical 
here.  If you want to use these features without restriction, secure 
boot is useless as you said, so don't use it.

Some people will still want to use secure boot because they find it 
useful - you might not, but there are a lot of people out there.  For 
these people, you have two options:  (1) block these features and/or (2) 
set them up so you can define exactly what they will be used for in your 
policy (if possible).  In other words, the kernel should make sure that 
it won't load anything it can't trust (especially things it can't trust 
not to load another kernel) while still providing as much features as 
possible.

This is the classic convenience vs security trade-off, and I don't think 
anyone is disillusioned about that "revelation".  I say again, if it's 
too inconvenient to have to configure/cripple/block these features, then 
you can't possibly use secure boot in a useful manner, and hence 
shouldn't even bother with it.  (Well, I know you know.)

> No vulnerability is needed.
>
> Which is why you will never have a trusted boot of an open Linux kernel.

I can't talk about the feasibility of securing the entire kernel, but I 
kind of got the feeling that Alan Cox knew more about it, maybe he can 
comment a bit on that (again).  I know a lot of smart people are 
thinking about it very seriously, so we shouldn't say it's impossible 
just yet.

I guess the main problem comes from virt done entirely in userspace, and 
I admit I have no clue what the plan is to address these.  I would hope 
some reasonable techniques exist for this already, or Microsoft wouldn't 
have invested so much in secure boot (they'd have the same issue 
afterall).  Some basic userspace initialization integrity checking would 
already go a long way I think.

>> Yes there is a process, indeed it doesn't require any third-party, and
>> no it doesn't blow anything up.
>
> No, there is no such process in existence right now. You just think that
> there will be, in the future.
>
> Not going to happen. No. Never.

If we're still talking about the process to add your own keys (that's 
what I was talking about anyway), know that it's confirmed by Microsoft 
for x86[0].  Now all vendors who don't comply [don't provide the 
interface to do it] won't be certified by MS.  They don't want that.

Why Microsoft would help here is certainly a bit of a mystery at first, 
but as I mentioned already, they certainly fear a PR and legal 
nightmare, because even if they don't explicitly require anything many 
vendors might not care to add the feature.  And then they'll most 
certainly happily hide behind Big Bad Microsoft, because 
"Windows-certified hardware won't boot alternative OSes on x86" (that 
already made the news even though it's wrong).  They would be quite 
right too, being an OEM kind of frees you from having to deal with 
end-users;  the problems with their products are delegated to the buyer, 
here, Microsoft.  So yes, it all makes sense in the end for MS to demand 
that of their vendors.

> Tell you what.
>
> Let's revisit this, when there's a key that will boot any Linux kernel,
> that anyone can build themselves, and install, ok?

Well the math doesn't compute here, it's cryptographically impossible. 
I mean you could sign a shim that won't verify the integrity of the boot 
loader, but you would gain absolutely nothing from secure boot then, it 
makes as much as disabling it entirely.

>> You're going meta. Who's gonna check the integrity of the firmware?
>> Can you
>
> I tell you who: Microsoft. And their OS, when it boots. The only way to
> work around it, would be copyright infringement.

I don't think we understand each other, I was joking.  It makes little 
sense for the OS to check the integrity of the firmware if the firmware 
itself is the one thing that verifies the integrity of the OS (via the 
loader).  I mean it's not even a real catch-22, you won't ever boot the 
kernel before the firmware, so this is a non-issue.  Anybody can sign 
all the firmwares in the world all day long, nobody's gonna care nor 
look at these signatures.

'Real sorry if I missed an obvious use-case here, but in any case it 
wouldn't part of secure boot I don't think.

> Anyway, that won't stop, of course, an OEM &/| Microsoft from suing
> anyone that produces hardware containing an image signed by a Microsoft
> key, but actually executes something else, that allows for an open boot.

Why would they sell their OEM arrangements (in the form of loaders 
signed with their own key) explicitly for people to load their own 
software if it's to sue them the day after?  I know they have a 
reputation to do crazy things, but it doesn't take a genius to see the 
problem in that business model.

Now if the loader they signed really allows for an open boot as in 
"executes anything without checking for integrity of the next component 
up until the point the user has complete control over what to execute 
next", well, see above, it's simply a stupid idea to begin with and they 
should blacklist it.


PS (OT):  I'm pretty confident we fell in there[1].  All in good fun 
though ;).  At least I hope so, else I apologize.  It's how it's done on 
the Internet.


[0] 
http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf
[1] https://xkcd.com/386/
-- 
t