SCIENTIFIC-LINUX-USERS Archives

October 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Wed, 19 Oct 2011 15:42:35 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (130 lines)
I apologize for the length of the popular press article that I am 
posting below -- however, the issue of MS controlling UEFI and thus 
preventing one from booting/installing Linux (or BSD or .. other than MS 
or presumably Mac OS X on an Apple branded machine) is significant and 
the article hits the main points.  Any ideas on a workaround?  Note that 
I and many of my colleagues run EL on workstations and laptops, 
accessing MS Win (when absolutely needed for a MS Win application not 
available under open systems) through VirtualBox or the like -- thus a 
server-only workaround will not be sufficient.

Yasha Karant

http://www.itworld.com/it-managementstrategy/207277/microsoft-washes-its-hands-uefilinux-mess

Microsoft washes its hands of UEFI/Linux mess
Shifts responsibility to hardware vendors
By Brian Proffitt

September 27, 2011, 7:00 AM —

REUTERS/Rick Wilking

Linux Australia is fit to be tied over recent reports that Microsoft is 
requiring Windows 8 certified machines to support UEFI secure booting, a 
situation that could most likely hamper or block Linux booting on such 
machines.

Indeed, Linux Australia is so ticked off, they plan to file a formal 
anti-competitive complaint against Microsoft with the Australian 
Competition and Consumer Commission (ACCC).

Unfortunately, all I can say is, good luck with that.

I am unfamiliar with the burden of proof the ACCC holds for such 
complaints, but I'm pretty sure Microsoft will be able to get itself off 
the hook for this one. Why? Because nothing in the language they have 
used to describe the UEFI secure boot process or the need for this 
process mentions other operating systems in any way. The case Microsoft 
has carefully and consistently made is that secure booting is good for 
Windows because it shuts down one more avenue of malware.

There's been some confusion about why the UEFI proposal is such a bad 
thing, so let's walk through it again, if I may beg your indulgence:

Red Hat developer Matthew Garrett blogged on Sept. 20 that according to 
the new Windows 8 logo rules, all Windows 8 machines will need to be 
have the Unified Extensible Firmware Interface (UEFI) instead of the 
venerable BIOS firmware layer. BIOS has been pretty much the sole 
firmware interface for PCs for a long time. Under Windows 8, BIOS will 
be gone, replaced by the UEFI layer.

And not just any old UEFI layer, either, but secure UEFI. Meaning a 
hardened boot process. This hardened boot means that "all firmware and 
software in the boot process must be signed by a trusted Certificate 
Authority (CA)," according to slides from a recent presentation on the 
UEFI boot process made by Arie van der Hoeven, Microsoft Principal Lead 
Program Manager.

It's the secure booting that puts Linux on the spot, because it means in 
order to be bootable on one of these Windows 8-certified machines, the 
Linux distribution will need to have certified keys from the 
manufacturer. Now, from a technical point of view, Garrett posted in a 
follow-up blog Friday afternoon, implementing such keys would be a 
week's worth of work.

Practically and legally, it's a whole different ball game.

First, there's the legalities. According to Garrett, GRUB 2 is licensed 
under the GPLv3, which means the signing keys may have to be provided 
along with the source code. It's fuzzy: the GPLv3 requires signing keys 
be released when hardware is sold with GPLv3 software that's encrypted. 
But if the signed software is used on someone else's hardware, then the 
keys are not required. It's not even clear with the GPLv2, the license 
for the original GRUB bootloader. In order to clear the ambiguity 
altogether, Garrett recommends a non-GPL bootloader.

But that scenario, as unsavory as it sounds, could be worse. Bootloading 
is one of the services that is being pulled into the Linux kernel, which 
is most definitely GPLv2, and isn't going to change.

And then there's the practical issue Garrett mentions: who's to say the 
OEMs are going to provide keys for Linux to hook into? Sure, they have 
to provide keys for Windows 8 if they want to be able to sell Windows 8 
on their hardware, but there's no rule that says they have to provide 
keys for anyone else.

Which is why I don't think Linux Australia's complaint has a hope of 
succeeding. Microsoft will argue--in fact, has argued in a rebuttal on 
this matter on Sept. 22--that this is a security matter for Microsoft 
Windows deployments, and they are in no way influencing what the 
hardware vendors are doing with their keys. Microsoft is not preventing 
other operating systems' keys from being handed out, and it's not their 
problem if the OEMs aren't accommodating to other operating systems.

The funny thing is, they're right. In one fell swoop, Microsoft has 
shifted the blame from their requirements to the actions (or inactions) 
of the OEMs. And why should the hardware vendors feel any pressure to 
provide keys, as Garrett summarizes?

     "Microsoft can require that hardware vendors include their keys. 
Their competition can't. A system that ships with Microsoft's signing 
keys and no others will be unable to perform secure boot of any 
operating system other than Microsoft's. No other vendor has the same 
position of power over the hardware vendors. Red Hat is unable to ensure 
that every OEM carries their signing key. Nor is Canonical. Nor is 
Nvidia, or AMD or any other PC component manufacturer. Microsoft's 
influence here is greater than even Intel's."

When this issue first came to light, it seemed to be a worry for desktop 
Linux alone. But as time went on, I began to wonder how many blade and 
rack servers come with that Windows Server certified logo. If Microsoft 
gets around to requiring UEFI secure booting for server hardware in a 
future version of Windows Server, then vendors like Red Hat and SUSE, 
who really don't play much in the desktop space, would take a serious 
hit if OEMs opted not to bother giving them keys. So would all the other 
Linux server distros.

For what it's worth, I don't see it coming to that. In server-space at 
least, vendors like IBM, HP, and Dell have too much invested in Linux, 
cloud, and virtual systems to prevent Linux installs. But in a world 
where barely any OEMs will even ship with Linux now, what incentive will 
hardware vendors have to provide keys for Linux distros?

For now, Microsoft isn't even bothering to argue these points, and from 
where I stand, they won't. If they are smart, they won't even mention 
complaints about other operating systems, and keep hammering home the 
point about security and malware. And, like a politician on a stump 
speech, that message will be drilled so many times it will even start to 
sound like the truth.

ATOM RSS1 RSS2