WINDOWS 8 SUPPORTED PC CAN'T RUN OTHER OS !!!
After years of trying to cut off Linux growth as a desktop platform on x86 and x64 PCs, Microsoft may have actually figured out a way to stop Linux deployments on client PCs dead in their tracks.
At the very least, Linux deployment will be hindered on any Windows 8-certified machines to come, as new requirements for the Windows 8 logo come to light.
Red Hat's Matthew Garrett was one of the first to notice that according to the new 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.
The EFI system has slowly been making headway in recent years, and right now EFI firmware is compatible with Windows supporting the GUID Partition Table (GPT), OS X/Intel, and Linux 2.6 and beyond machines. EFI is seen as a better hardware/software interface than BIOS, since it is platform-agnostic, runs in 32- or 64-bit mode, and GPT machines can handle boot partitions of up to 9.4 zettabytes. (That's 9.5 billion terabytes to you and me.)
EFI, and the later UEFI specification, is not the problem for Linux. The problem is Microsoft's other requirement for any Windows 8-certified client: the system must support secure booting. This hardened boot means that "all firmware and software in the boot process must be signed by a trusted Certificate Authority (CA)," according toslides from a recent presentation on the UEFI boot process made by Arie van der Hoeven, Microsoft Principal Lead Program Manager.
The slides, posted on Garrett's in a blog Tuesday afternoon, reveal Microsoft's plan to lock down the boot process, which Microsoft rightly points out has become a high-value target vector for injecting malware onto Windows PCs. To combat this, Microsoft is requiring all Windows 8 devices to have a hardened boot. Right now, even though there are EFI-ready Linux bootloaders and distros available, none of them are signed, Garrett reminded me.
It's not just a matter of replacing the UEFI system on the device with other, unencrypted, firmware. If all parts of the chain need to have a CA signature, then swapping out a machine's signed EFI layer with, say, an unsigned BIOS or EFI would not work. Garrett described the problem in more detail:
"Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. The two alternatives here are for Windows to be signed with a Microsoft key and for the public part of that key to be included with all systems, or alternatively for each OEM to include their own key and sign the pre-installed versions of Windows. The second approach would make it impossible to run boxed copies of Windows on Windows logo hardware, and also impossible to install new versions of Windows unless your OEM provided a new signed copy. The former seems more likely."
The upshot? Any device that ships with the manufacturer's keys and Microsoft's keys will not be able to boot a vanilla version of Linux.
The obvious solution--getting Linux distros signed so they can load on these machines--is clouded with uncertainty.
"Firstly, we'd need a non-GPL bootloader. Grub 2 is released under the GPLv3, which explicitly requires that we provide the signing keys. Grub is under GPLv2 which lacks the explicit requirement for keys, but it could be argued that the requirement for the scripts used to control compilation includes that. It's a grey area, and exploiting it would be a pretty good show of bad faith. Secondly, in the near future the design of the kernel will mean that the kernel itself is part of the bootloader. This means that kernels will also have to be signed. Making it impossible for users or developers to build their own kernels is not practical. Finally, if we self-sign, it's still necessary to get our keys included by ever OEM."
That's a whole lot of unsavory options to look forward to.
Garrett, for his part, is not panicking about the new requirement. He's hopeful that OEMs will be able to include an option in their UEFI firmware to disable the secure booting feature. Even if that is allowed by Microsoft, one thing is clear: dual-booting systems will be out of the picture if Windows 8 boots always require a hardened boot environment. It may very well be that once you turn off secure boot (if you can), you won't be able to run Windows 8 again on that machine, until you re-secure the boot process.
Microsoft is spinning this as a way to finally lock down the boot process, but I can't help but wonder if the side-benefit of blocking Linux boots was something expected as well.
Something to which we need to pay attention, that's for sure.
