Windows 8 has been mired in controversy ever since it was announced, from the abandonment of the Start menu, the choice of the ribbon interface, to the inability to create decent alternative browsers for Windows 8 ARM-based tablets. One of the controversies has been the surrounding Secure Boot and its affect on the Linux ecosystem.
BIOS has been the been means for booting into computers from a long time, however it is an ageing technology, and it has a successor, UEFI. With Windows 8, Microsoft will make it mandatory for any manufacturer seeking Microsoft certification to support UEFI. More importantly it also mandates that such computers support a UEFI feature called Secure Boot.
Secure Boot, as its name suggests, is a security feature that—if supported by hardware—can make the boot process much less vulnerable to viruses and other malware. The way UEFI and Secure Boot do this is to only execute an operating system’s boot loader and drivers if they are signed by an accepted boot loader.
The controversy stems from the fact that hardware manufacturers might choose to only enable Microsoft’s digital signature, and refuse to boot any other system. This would make it impossible to boot Linux or any alternative OS. Microsoft however made it a requirement from hardware manufacturers that the user be able to turn off secure boot, which gives Linux users an option to boot without the secure boot feature.
However, while Microsoft made it mandatory for hardware manufactures to support disabling secure boot on x86 hardware, this is not applicable to ARM-based computers. For ARM-based hardware Microsoft mandates that Secure Boot should be turned on, and there be no way to disable it. This effectively locks out users from installing Linux on ARM-based tablets and netbooks running Windows 8 RT.
Secure Boot is a great feature for security, and one that Linux distros too can benefit from, however they also take away some of the flexibility offered by Linux, such as choice of boot loaders, custom kernels etc. If Secure Boot is enabled such software will have to be signed, which is not always possible, especially for rolling distros such as Arch and OpenSUSE Tumbleweed, or if the user compiles their own kernel. Even for distros that opt to support and enable Secure Boot, and disallow changing the kernel, they will be required to get their OS signed by Microsoft.
Secure Boot uses a complex hierarchy of keys that decide what actions a user can take, you have the Platform Key (PK), the Key Exchange Key (KEK) and the Signature Database (db). For any software to be able to boot, it might be signed by one of the keys that exits in the Signature Database, or it has an SHA-256 hash that is in the db. There is also a Forbidden Signatures Database (dbx), that has keys forbidden from execution; anything signed using a key in the dbx, having its signature in the dbx or having its SHA-256 hash in the dbx will not be allowed to boot.
So the solution to booting anything is sign it with one of the keys that are in the Signature Database, or to append your key to the db. However to add a key to the db, you need to authenticate such an action using the KEK. The KEK itself can only be changed is action is authorized by the PK. The ultimate authority, as you can see, lies with the Platform Key (PK). This can only be changed if Secure Boot is turned off and the hardware is in Setup Mode.
Now all this is well and good, people have options—at least on x86 systems—but for most users this might be too complex to handle, and they will simply lose the incentive to use Linux at all. Different Linux distributions have come up with different solutions.
Linux distributors can convince hardware vendors to include their keys so that users can install that particular distro on their computer. This can work for Ubuntu, Red Hat / Fedora, OpenSuse and other larger distros, since they have the influence to reach hardware vendors but what about something a smaller distro like CrunchBang? Even for these major distros, ensuring that their key is included on all hardware can be difficult.
Another option is to ask users to disable Secure Boot, in which case the benefit of this technology is lost. Or they can ask users to put their computers in setup mode, in which case the distro can install its own key and use that for securely booting in the future. The problem with this—and disabling secure boot—is that it requires the users to be aware of this issue and have sufficient knowledge to deal with their system’s mechanism for these features. Each platform will likely have its own implementation and UI further making it difficult for users since they need to be aware of their system’s configuration.
What some Linux distributions such as Fedora and OpenSUSE are doing is to have their own pre-boot-loader which is signed using a Microsoft Key and will thus boot on all systems that Windows 8 itself can boot on. This pre-bootloader then verifies that the next stage boot loader, which would be GRUB 2, the actual boot loader is signed using the distro key. This allows those distros to publish updates with needing to have them signed using a Microsoft key each time, since they can just be signed using their own key which they have control over.
The approach taken by the Linux Foundation is similar. They intend to to create a small pre-boot-loader signed using a Microsoft key that further loads the real boot-loader that boots the OS. This pre-boot-loader doesn’t require the actual boot loader to be signed, so it effectively nullifies the security feature of Secure Boot in favour of giving the user the choice to boot the distro of their choice.
This however is not so bad. The way the Linux Foundation’s pre-bootloader will work is to load the next bootloader whether Windows or Linux (GRUB2), and if the next bootloader is signed, then things will boot as normal. If however the next bootloader is not signed, perhaps it is a smaller distro, or a live CD, then this pre-bootloader will ask the user to confirm if they want to continue booting. This prevents any malware from booting without permission as for a user used to secure boot, such a warning will be out of place.
Since this would be tedious for repeated boots, this pre-bootloader will also give the user the option to install the unsigned bootloader to the list of authorized binaries list, if the system is in setup mode. The warning screen while loading an unknown bootloader will also point users to the Linux Foundation website where they can learn more about this issue and how to put their system in setup mode.
This is intended to be a stop-gap measure, to be used by smaller distros while they look for their own solutions. In the mean time larger distributions can have their own means for booting that take advantage of Secure Boot.
As Windows 8 and Windows 8 certified hardware seem to be just in the horizon more solutions are beginning to appear, and hopefully in a few months time and more distros are released this issue will disappear.
