Windows secure boot controversy gets uglier.
In previous news items, we’ve described the possibility of a Linux lock-out under the new UEFI secure boot feature. Briefly, the new UEFI specification, which will be part of Windows 8, associates the firmware with a signing key, which prohibits users from installing a new operating system. Because the majority of Linux desktop systems are installed over a previous OEM version of Windows, this is cause for concern.
In a couple of recent posts, Red Hat engineer Matthew Garrett explains the UEFI situation further. He also gave a talk about it at Linux.conf.au 2012. Basically, it’s ugly and getting uglier. For example, although Microsoft’s certification requirements state that all systems must support a custom mode, implying that users could install their own keys, Garrett says this solution is not good enough. He says: “People have spent incredible amounts of time and effort making it easy to install Linux by doing little more than putting a CD in a drive. Asking them to go into the firmware and reconfigure things adds an extra barrier that restricts the ability to install Linux to more technically skilled users.”
To add fuel to the fire, in December, Microsoft published the “Windows Hardware Certification Requirements,” which details the requirements for Windows 8 Certified Systems. Page 116 says:
“MANDATORY: Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of Pkpriv. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure MUST NOT be possible on ARM systems.”
This mandate would specifically prevent non-Windows operating systems from being installed on ARM-based devices shipping with Windows 8. Still, it’s up to OEMs to decide whether they want to comply with Windows 8 Certification Requirements to the letter. We’ll have to wait and see.