Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

Sam Varshavchik mrsam at courier-mta.com
Fri Jun 1 03:34:17 UTC 2012


Edward M writes:

> On 05/31/2012 07:18 PM, Sam Varshavchik wrote:
>
>> positive and confident that this entire kit-and-kaboodle has no choice but  
>> require a closed, hood-welded-shut OS, booted up with a signed chain, in  
>> order for it to work.
>
>      Oracle Solaris?

Yes, I think that would qualify.

I would truly like for someone who is a lot more knowledgable than me, in  
this area, to answer the following short list of simple questions for me.  
Please, I'm desperate to know the answers to the following. Someone, please  
have pity on me. I'm just feeling particularly stupid today, so someone  
needs to patiently explain this to me:

We're told that Fedora's bootloader is going to get signed – and by that,  
that must mean "grub", right?

And, grub can boot an arbitrary Linux kernel, right?

So, a virus that wants to compromise a signed, secure bootload chain, can't  
it simply install Fedora's signed grub, configured to boot a bare-bones  
Linux kernel, nothing will prevent that, right?

And, Fedora can load any kernel module, right? Hence, load the virus code  
onto "bare metal", right?

Then, can't the loaded virus code simply reboot back into the original,  
Windows bootloader, that's now infected, and simply do what the virus  
would've done originally, in the absence of a signed bootloader, right?

If so, then what the FSCK did having an option for a signed bootloader  
accomplish, here???

I don't have any answers to these questions (like I said, I'm feeling a bit  
stupid today), but I do know one thing for sure. If everything that what's  
been publicly said on this subject, so far, is true, then:

Someone around here is a bloomin' idiot of the first degree. An absolute,  
total, clueless moron. Complete, and total, brain damage. That could be  
either myself – a possibility that I am perfectly willing to admit – or  
Microsoft; or whoever's pushing this.

The other possibility, of course, is that most of what's been publicly  
stated about this subject, has either been a complete lie or a fabrication;  
or certain crucial, fundamental details about this process, have been  
omitted. It just /cannot/ work the way it's been publicly announced.

Now, let me make a prediction of what I think is /really/ going to happen.  
After thinking about this, oh, for maybe five minutes, tops, I think I have  
up with the only answer that makes any logical sense, given everything  
that's been publicly said. With apologies to Sir Arthur Conan Doyle, whose  
literary masterpiece I'm about to butcher: when you exclude all  
possibilities that are logically impossible, whatever's left, no matter how  
highly improbable or bizarre, must be true.

What I'm convinced that this is all about, is that Red Hat will simply get  
Microsoft to sign a bootloader that will boot a kernel that's signed with  
Red Hat's private key. The kernel will be configured to load only kernel  
modules that are also signed by Red Hat's private key. OEMs that supply OEM  
binary blobs, for stuff like RAID cards, etc, that are certified with RHEL,  
will get Red Hat to sign their kernel modules for them, also for a token  
certification key. That's the hood, welded shut, that's absolutely mandatory  
for a secured bootloader to have any logical purpose, whatsoever.

Based on publicly known information to me, this is the only situation that  
makes any sense. Nothing else could possibly work, in any logical fashion.

Fedora is not going to be a part of this. In order to boot Fedora, it will  
be necessary to disable the secure bootload, on the hardware.

I welcome anyone to explain what part of the above is logically false, and  
why.

-------------- 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/20120531/02cb9a87/attachment.sig>


More information about the users mailing list