Microsoft's UEFI Rules Could Be Used To Block Linux Installation
Microsoft discussed the upcoming changes to Windows 8's boot process at BUILD last week, but Matthew Garrett, a mobile Linux developer and blogger at Red Hat has pointed out that the company's new requirements could be used in ways that harm the Linux community. One of Microsoft's new rules for Windows 8 is that any company that ships a windows 8 device must enable UEFI secure boot.
Secure boot uses signing keys to ensure that only verified, trusted hardware (and associated drivers) are allowed to boot the system or run once the system has booted. There are separate sets of keys for the boot process and OS/firmware communication. Garrett writes:
Whether or not this becomes a problem depends more on device manufacturers than it does on Microsoft. The UEFI secure boot functionality is something end users can enable or disable at will from within the UEFI framework--provided that the manufacturer leaves this option available. Not doing so would prevent the installation of Linux, Windows 7, or any other OS. It would also prevent unauthorized driver updates or certain software installations.
Windows 8's use of UEFI is essential to speeding up the boot process. The current model is literally decades old
Anyone wanting dual-boot a tablet OS, install something other than Windows 8, or just concerned about device freedom will want to keep an eye on which manufacturers intend to offer a toggle and which don't. Microsoft's rules state that a windows 8 device must ship with Secure Boot enabled, but do not state that the mode must be locked on. Garrett also notes that Red Hat could potentially provide its own signed code, but not in a way that's consistent with Linux design philosophy or the idea of rolling one's own kernel.
Secure boot uses signing keys to ensure that only verified, trusted hardware (and associated drivers) are allowed to boot the system or run once the system has booted. There are separate sets of keys for the boot process and OS/firmware communication. Garrett writes:
An OS vendor cannot boot their software on a system unless it's signed with a key that's included in the system firmware. A hardware vendor cannot run their hardware inside the EFI environment unless their drivers are signed with a key that's included in the system firmware. If you install a new graphics card that either has unsigned drivers, or drivers that are signed with a key that's not in your system firmware, you'll get no graphics support in the firmware.
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.
Whether or not this becomes a problem depends more on device manufacturers than it does on Microsoft. The UEFI secure boot functionality is something end users can enable or disable at will from within the UEFI framework--provided that the manufacturer leaves this option available. Not doing so would prevent the installation of Linux, Windows 7, or any other OS. It would also prevent unauthorized driver updates or certain software installations.
Windows 8's use of UEFI is essential to speeding up the boot process. The current model is literally decades old
Anyone wanting dual-boot a tablet OS, install something other than Windows 8, or just concerned about device freedom will want to keep an eye on which manufacturers intend to offer a toggle and which don't. Microsoft's rules state that a windows 8 device must ship with Secure Boot enabled, but do not state that the mode must be locked on. Garrett also notes that Red Hat could potentially provide its own signed code, but not in a way that's consistent with Linux design philosophy or the idea of rolling one's own kernel.
