Biz & IT —

Windows 8’s locked bootloaders: much ado about nothing, or the end of the world as we know it?

Microsoft's secure boot policy for Windows 8 has some Linux advocates up in …

Windows 8's locked bootloaders: much ado about nothing, or the end of the world as we know it?

Microsoft has published the hardware requirements that manufacturers must follow if they want to slap a "Designed for Windows 8" sticker onto their systems. In among many innocuous requirements—multitouch systems must support at least five points of touch, there must be at least 10 GB of free space available to the user, and more—are a set of requirements for Windows 8 systems' firmware. These requirements have reignited Linux users' fears that they will be locked out of Windows 8 hardware.

The concerns revolve around the use of a new feature called UEFI Secure Boot. All Windows 8 systems that meet Microsoft's certification requirements must use UEFI firmware with Secure Boot enabled.

UEFI: a BIOS fit for the 21st century

Unified Extensible Firmware Interface is a relatively modern replacement for the ancient PC BIOS; it handles basic tasks such as initializing the machine, probing its hardware, and passing control to an operating system. Unlike the BIOS, which was intimately coupled to the vagaries of x86 processors and tended to be both slow and difficult to extend, UEFI is designed to be a processor-independent, modular, extensible system capable of much faster boot-ups.

UEFI's predecessor, EFI, was developed for x86 and Itanium systems by Hewlett-Packard and Intel. In 2005, UEFI supplanted EFI, and added support for x86-64 and, with its most recent update, ARM systems. EFI and UEFI have taken a long time to penetrate the market. EFI was never used much—Itanium systems, a handful of oddball x86 PCs, and Intel-powered Macs all used it—but UEFI has started to become widespread. The need to replace the PC BIOS has become acute, since it cannot boot from hard disks that are larger than 2 TB, and so the industry has at last abandoned the BIOS: most motherboards for Intel's Sandy Bridge processors use UEFI.

Securing the boot process

Since UEFI's first version (2.0, released in 2006), it has supported the use of digital signatures to ensure that UEFI drivers and UEFI programs are not tampered with. In version 2.2, released in 2008, digital signature support was extended so that operating system loaders—the pieces of code supplied by operating system developers to actually load and start an operating system—could also be signed.

The digital signature mechanism uses standard public key infrastructure technology. The UEFI firmware stores one or more trusted certificates. Signed software (whether it be a driver, a UEFI program, or an operating system loader) must have a signature that can be traced back to one of these trusted certificates. If there is no signature at all, if the signature is faulty, or if the signature does not correspond to any of the certificates, the system will refuse to boot.

The purpose of all this is, as the name would imply, to provide security. Windows itself ensures that its own executables (and, on 64-bit versions, all drivers) contain valid signatures, in an effort to ensure that malware and rootkits have not tampered with any critical system files.

However, the weak link in this chain is the initial operating system loader; if this is modified so that it no longer validates digital signatures, it could load a modified operating system kernel. There are extant, real-world rootkits that do just this: they modify the Windows boot loader so that it no longer verifies the integrity of the files that it loads. This allows the rootkit to modify the Windows kernel so that it can evade detection. Secure boot stops this kind of attack in its tracks.

For a Windows 8 system to pass Microsoft's certification criteria it will not only have to use UEFI; it will also have to have secure boot enabled. This means that every Windows 8 system must include the Microsoft certificate in its list of trusted certificates, and it must verify that the Windows 8 operating system loader is untampered with.

That core requirement is common to both x86 and ARM platforms. The details, however, are very different between the two.

x86: freedom and flexibility

x86 Windows 8 systems must allow users to add and remove certificates from the firmware's certificate store. For example, a Linux vendor could provide a signed operating system loader and corresponding certificate: all x86 Windows 8 systems must permit users to install such certificates. Microsoft calls this "custom mode", in contrast to "standard mode", that includes only the Microsoft certificate.

x86 Windows 8 systems must also allow secure boot to be turned off completely, so that no certificate verification is performed at all.

UEFI allows the ability to drop back to mimicking BIOS, to allow UEFI systems to start pre-UEFI operating systems. This is done through a combination of running the "option ROMs" embedded into many components, and Compatibility Support Modules (CSMs) to hand over control to a legacy operating system.

Windows 8 machines using x86 processors can offer this kind of backwards compatibility, but they must not invoke it without explicit user action; in other words, this "BIOS mode" must be explicitly enabled. Further, if secure boot is enabled, the system must not enter BIOS mode at all. Systems with 32-bit Windows can even ship in BIOS mode by default, though they must still be capable of UEFI mode.

This combination of options should settle most concerns that were raised when news of the secure boot requirement first broke. On x86 systems, Windows 8 stands as no impediment to using non-Windows operating systems. Indeed, Microsoft's rules ensure that vendors will make it possible to securely boot operating systems other than Windows: system builders will have no choice but to allow system owners to install their own certificates.

The rules should also ensure the system remains secure; in all cases, weakening the system's integrity (by adding certificates or disabling secure boot entirely) should require physical console access, and shouldn't be possible programmatically. In other words, there should be no way for a rootkit to silently add its own certificate to the trusted store or otherwise defeat the system.

ARM: restriction and control

The story for ARM is rather different, however. On ARM Windows 8 systems, Microsoft's certification rules prohibit entering "custom mode"—users must not be able to add certificates of their own—and prohibit disabling secure boot completely. The ARM systems will all require the use of a signed operating system loader, and that operating system loader must be signed by Microsoft.

Microsoft's rules also specify that a secure boot failure must be fatal; there must be no option to override the failure and choose to boot the untrusted operating system.

Further, manufacturers will be prohibited from shipping updates to their firmware that relax these restrictions; all firmware updates must be protected with digital signatures and must preserve the secure boot settings. They should also prevent the installation of older firmware versions—for example, downgrading the firmware to switch to a version with a known security flaw—though the manufacturer can allow this particular constraint to be manually overridden.

Taken together, the situation for ARM machines is essentially the diametric opposite of the situation for x86 systems. The x86 requirements give the user the power to do what they like; boot an operating system of their choosing, and do so either securely or insecurely. On ARM? They'll boot Windows, and they'll do so securely.

This leaves exactly two options for booting any other operating system: find a security flaw in the firmware, and hope it doesn't get patched, or hope that Microsoft will produce a suitable boot loader. The former is plausible—it does happen from time to time. The latter is highly unlikely.

You don't have to be open to be successful

Microsoft's stance is not without precedent. Locking appliance-like systems is commonplace. The best-selling tablet in the world, by a large margin, has a locked bootloader. The iPad can run Apple's operating system, and no other. While occasional flaws in the iPad's software and bootloader might from time to time enable that situation to be challenged, such challenges come in spite of Apple's efforts, not because of them.

The iPad is not unique in this regard, either; the ill-fated BlackBerry PlayBook shipped with a locked bootloader. So did most Samsung Galaxy Tab 10.1s. Asus' Eee Pad Transformer Prime also has a locked bootloader, though Asus says it will relent and provide a tool to unlock the bootloader soon. Barnes and Noble's NOOK Tablet is also locked.

Locking isn't universal, mind; some, such as the Motorola Xoom, can be unlocked with the manufacturer's consent (though doing so will typically void the product's warranty). HTC has recently released a program to unlock the bootloader of its Android smartphones, again without warranty or support.

What's more, ARM-powered Windows 8 machines won't be confined to the narrow tablet category. Qualcomm has announced plans to produce thin-and-light Windows 8 laptops that use its Snapdragon ARM processors.

Microsoft's decision certainly isn't universally popular, with software freedom advocates and Linux supporters both coming out against Microsoft's policy, claiming that it deprives users of these machines of some essential right. Others argue that since there's no other operating system that will run on Windows 8 ARM machines there's nothing lost by not being able to disable secure boot, and hence the entire fuss is a non-issue.

Competing concerns

The discussion tends to conflate practical concerns—is disabling secure boot useful—with (perceived) moral imperatives (should end-users have the right to install whatever they like?), questions of marketability (will people reject ARM machines that do not support the installation of other operating systems) and ontological concerns over what it means to be a computer, and the implications that has for our expectations.

In a practical sense, there is some truth to the argument that it doesn't matter. The main reason that people unlock the bootloaders of their Android devices is so that they can run Android kernels other than those that their device's manufacturer has specifically blessed. Android is substantially open source, and so third parties are able to compile their own kernel binaries. Since these third-party kernels lack any digital signature, a bootloader that's locked and requires signature is a serious impediment.

Windows 8, of course, won't be open source. Windows 8 users might potentially want to "root" their operating systems, to for example allow side-loading of applications, but Windows 8 won't ever have a community of developers producing third-party kernels. As such, there's no direct equivalent to the Android scenario.

In principle, some users might want to buy a Windows 8 ARM machine and then install Android, Ubuntu, or some other operating system on it. Even if secure boot could be disabled, it's unlikely that this could be done overnight; unlike x86 systems, which all look more or less identical from an operating system's perspective, ARM has few conventions: any Android port would have to be tailored to accommodate the particular vagaries of the boot process and hardware capabilities that ARM Windows 8 machines have (though it is likely that all Windows 8 ARM machines will be consistent in this regard, in spite of using processors from different companies).

As the efforts to port Android to the HP TouchPad have shown, it's likely that a suitable Android port would be assembled—if only it could boot. The secure boot mandate puts an end to such efforts even before they have started. As such, this position, while accurate enough in the short term, looks increasingly circular as the timescale increases—the only reason that there would be no other operating systems would be because secure boot precluded the development of other operating systems.

Nonetheless, even if such an Android port were available, it's not likely to have mass appeal. It would be of great interest to a minority of users, and of no interest at all to the great majority—just as is already the case with dual-booting or running a custom Android build. As such, it's hard to imagine any significant impact on Windows 8's sales as a result of this decision. The ability to run other operating systems is barely even a consideration on PCs, let alone appliances.

Bulletproof reliability

And "appliance" certainly seems to be what Microsoft is aiming for with these rules: robust, essentially single-purpose devices that just work with no fuss or unnecessary complexity. These devices need to be bulletproof, and that means not only protecting against errant and hostile software—hence the use of the Windows 8 Store for application distribution—but also against errant and hostile users. No matter how misguided or malicious a user is, it should never be possible for them to render an appliance unbootable. This is what the iPad does so well, and what Redmond is trying to emulate for Windows 8.

Awkwardly, however, this stands in contrast to Microsoft's historical position on the tablet. The company has long maintained that the tablet is a kind of PC, and at least for x86 machines, it seems to be sticking to that mantra. For ARM, however, that appears to have fallen by the wayside; ARM machines will be less complex but also less capable. They won't offer the full power of the PC.

Appliance-level robustness has certainly proven popular in tablets. It might play less well with devices such as Qualcomm's ARM laptops—particularly if some or all ARM systems retain access to the Windows desktop. We think that there are good reasons to retain the desktop on at least some ARM machines (as well as good reasons to exclude it from others), and a hypothetical ARM laptop would certainly be a good candidate for retaining the traditional desktop.

Conventional form factors and a conventional desktop might in turn lead to a demand for conventional capabilities, including the ability to mess with the operating system (and even break it). Just as with dual-booting, this is a niche demand, but with the enormous breadth and diversity of the PC, even a small niche can be a lot of people.

The free software community would argue that this kind of restriction on how a device can be used is an unacceptable curtailment of user freedom, and that if you bought a device you should have free rein over both the hardware itself and the software running on it. Certainly, the argument that intuitively a computer that you own should run the software of your choosing and be beholden to you and not some third party is compelling.

But in practice, people are willing to forfeit such freedoms if it is useful to do so. The inability to, for example, install arbitrary software on an iPad is a negative, but the greatly reduced amount of malicious software that results from this restriction is a great positive. Tales of end-users doing dangerous or destructive things to their own computers are rampant, and there is a genuine question to be asked here: are these people better served by a full-power "free" computer, or a restricted "non-free" computing appliance that will always work? Computers are meant to be useful, functional items, and for many, freedom hinders that goal more than it ever helped it.

In spite of this, we might still prefer a solution of the kind used by Google for its Chromebooks. Chromebooks are highly restricted, including a bootloader that will only run Google-signed kernels. However, they can be de-restricted through a combination of flicking a physical switch and entering certain software commands. Further, a second physical button will force them into recovery mode, in which they revert to secure boot, and must be provided with USB media containing a new operating system with a valid signature.

There's no way in which the security systems can be defeated accidentally, nor any way that they can be defeated by malicious software. The Chromebook approach also ensures that systems can be robustly recovered. It arguably achieves all the security and reliability requirements that Microsoft might have, while still keeping everyone happy.

A question of influence

Even if Microsoft's position doesn't change, the impact its rules will have may prove to be negligible in practice. x86 hardware will retain all the freedom and flexibility that users of alternative operating systems need. Unlocked ARM hardware is also going to continue to be widely available; it'll just come with Android rather than Windows. Given Android's much greater strength in the tablet market, it's all but inevitable that Windows 8-only hardware will be a minority. Microsoft doesn't have the market dominance to take away everyone's ability to use alternative operating systems.

If every future PC and tablet were restricted so that it could only boot a Microsoft operating system, there would indeed be the end of the world as we know it; it would fundamentally alter the nature of the PC, converting it from the supremely flexible device that it is into a well-decorated prison cell. As it is, it will simply be a choice that buyers have to make for themselves. There will be options that are locked down, including the iPad and Windows 8 ARM tablets. There will be options that are not. The decision as to which is more important—freedom or reliability—will lie with the user.

Listing image by Photograph by Mike

Channel Ars Technica