Microsoft washes its hands of UEFI/Linux mess
Shifts responsibility to hardware vendors
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.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.