Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

[Sam Varshavchik]

Thibault Nélis writes:

> On 06/01/2012 02:33 PM, Sam Varshavchik wrote:
>
>> If the shim enables anyone to execute any code they wish, "on bare
>> metal", it makes the entire concept of trusted boot completely and
>> totally moot.
>
> Not anyone, just Fedora.  If Fedora starts to fuck up and many Windows users  
> report being infected, and it turns out that hackers are using vulnerable  
> Fedora kernels to host malware and chainload to Windows, then they will  
> blacklist the shim.  Since Fedora doesn't want that, the kernel maintainers,  
> the boot loader maintainers, and the shim maintainers will make sure that  
> nothing is vulnerable on their end, and keep the key secure.

I don't think the whole picture is fully understood. There does not have to  
be any vulnerability, for a common definition of "vulnerability", for this  
to occur.

Right now, there is a documented set of kernel features, in every stock  
Linux kernel, that can be used to instruct the kernel to cease all activity,  
and execute arbitrary code; boot another OS, if you want. I'm being  
deliberately vague.

But they've been in Linux for ages. They are documented, just not widely  
known. This is not a "vulnerability". This feature is used by pretty much  
every enterprise Linux seat. On one memorable occasion, circa 4-5 years ago,  
my "enterprise" job at that time had to deal with a pesky RHEL kernel bug.  
With some assistance from RHEL engineering, the particular feature in  
question was used it to gather diagnostics, isolate, and track down where  
the kernel bug is. It's not actually being used to boot another OS, but to  
implement different functions that are often needed in enterprise  
environments.

And I used it myself, on occasion, for the same reasons. I think I still  
have it turned on, on one of my headless servers, currently on F16, soon to  
be on F17.

If such a mystery beast, as a signed Fedora kernel, emerges; where "kernel"  
refers to the standard Linux kernel, no more modified than it is already  
modified in Fedora, right now, then malware can simply take the signed  
Fedora kernel. Boot it. Then tell the kernel to invoke this specific  
feature, in order to execute the virus code.

This is what being an open OS is all about, folks. The OS does not prohibit  
you from accessing the underlying hardware. You are free to halt the OS, and  
execute your own code, at any time.

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.

No vulnerability is needed.

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

Really, I feel no point in discussing this if something this fundamental  
cannot be comprehended or understood. I simply can't find a better way to  
explain this.

Now, if Microsoft wasn't around, then, yes, you could possibly have  
something like this trusted boot come about.

But not when the same hardware needs to run a non-free OS.

As I mentioned elsewhere, the only end game I see here, is hardware that  
either supports non-free OSes, or free OSes. But not both. If you want a  
trusted boot environment, you cannot support both free and non-free OSes on  
the same hardware.

This is fundamental. Nothing, no $100 cockamamie certification process, no  
PR bullshit spin, could possibly change this fundamental property, in any  
shape, way, matter, or form. Either accept this concept, or don't, but I  
don't think I can explain it any more clearer.

>> And, if there's a process by which my own signing key acquires the
>> magical pixie dust, that does not involve, in any way whatsoever, any
>> outside party giving their stamp of approval, that blows the entire boot
>> loader trust chain wide open.
>
> 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.

>> This is the pie in the sky.
>>
>> This part, is not going to happen. Microsoft will make sure of that.
>
> Another bet?  As Alan Cox said, the public outrage if it doesn't happen will  
> be immense,

Maybe somewhere in the EU, perhaps. I do not believe that it will be enough.


> Nothing is lost yet, and awareness is raising even before the release of the  
> technology.  I know the fight isn't won yet either, but if everyone does its  
> part we won't even have to lift a fist, and judging by what Microsoft is  
> doing offering $100 signatures via Verisign (which isn't very expansive for

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?

>> I'm going to throw in another 1,000 quatloos on a different bet.
>> Microsoft will also require OEM's boot firmware to be signed by
>> Microsoft's key, in order for a Microsoft OS to boot off it. Otherwise,
>> the user will be greeted with a nicely-rendered message that their
>> hardware is incompatible.
>
> 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 have a dim recollection of a case from a few years ago that has some  
relevance. I remember pretty much nothing of it, but I recall it was some  
kind of a smart-card related situation, where some hardware checked a few  
bytes on the smart card, that carried the manufacturer's name on it. A  
competitor made their own cards, and put the same bytes on their smart- 
cards, so that it works with the hardware in question. They were sued, for  
copyright infringement; the judge ruled against them. It might not've been  
smart-cards, it might've been one of the portable gaming platforms.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20120601/f33e2005/attachment.sig>