Microsoft requires UEFI “secure” boot for Windows 8 certified hardware. More security is good, right? Even if it locks out Linux?
Microsoft is requiring Windows 8-certified hardware to ship with UEFI Secure Boot enabled. This prevents installing any other operating systems, or running any live Linux media. There are ways to get around Secure Boot– but why should we, once again, have to jump through Microsoft hoops just to use our own hardware the way we want to?
What is UEFI?
UEFI is the Unified Extensible Firmware Interface, a new firmware to replace the elderly and inadequate PC BIOS we’ve been using since the dawn of the x86 personal computer era. The PC BIOS (basic input output system) supports only 16-bit processes and 1MB of memory addressing, so it performs only the minimal tasks necessary to start a computer, and then hands off to the next-stage bootloader, like GRUB, LILO, or Syslinux. We’ve been shackled to the 4-primary partition master boot record, and unable to boot > 2.2TB hard disks because of the PC BIOS.
UEFI was originally EFI, which was developed by Intel as a modern alternative to the PC BIOS. Now it’s supported by a big ole industry consortium populated by pretty much everyone in tech. UEFI is really a little operating system, so it can be programmed to do just about anything: boot fast, play games, allow remote access without starting the operating system, shutdown, Web surf, and all those things that the Linux pre-boot environments promised. It supports both a pretty mouse-driven graphical interface, and a console interface. It has its own networking stack, and supports its own set of device drivers so you can have video, networking, peripherals, and other functions available during pre-boot. It has its own built-in boot menu. It has 32-bit and 64-bit modes. It boots > 2TB hard disks and uses the GUID (globally unique IDs) partition table instead of the moldy old MBR. There is a still a limit on the size of hard disks it can boot — 9.4 zettabytes. I expect that most of us will be able to deal with that limitation.
Figure 1: A simple diagram that shows where UEFI fits in system startup.
(Image courtesy Wikimedia Commons)
UEFI supports two types of services: boot-time and runtime. Boot services are available while the UEFI firmware controls the system, and runtime services are available both during firmware control, and after the operating system takes over. UEFI has a BSD-licensed core, and then vendors can customize extensions as they like, including closed-source drivers, support for legacy operating systems, and other extensions.
Of course all this flexibility and feature-ful goodness comes at a price: the core source code contains over 7000 files and over 100MB of code. It’s about 10 percent the size of the entire Linux kernel, and if you remove all the drivers from the kernel UEFI is bigger than the core kernel. Which is a fair comparison, because most UEFI hardware drivers are not in the core.
It would take a few articles to write a detailed UEFI overview. Check out the UEFI specification to learn more. It’s over 2,200 pages, but it is a free download and the first few chapters are informative even for non-developers.
Not All Skittles and Beer
The PC BIOS was long overdue for retirement, but is UEFI an improvement? UEFI is huge, and it duplicates a lot of operating system functionality. More code equals more features. It also means more bugs, and more potential vulnerabilities, which is worrisome in a pre-boot environment that holds to the keys to every part of your computer, all of your software and hardware.
Why Secure Boot?
Windows has become somewhat less vulnerable in recent years, partly because of tools like validation checkers. There is a chain of validation that goes something like this: The bootloader asserts that the kernel has not been tampered with, and allows it to boot. Microsoft has required signed drivers for the past few years, so the next step is for the kernel to verify driver signatures. Then when users run a malware scanner they have a reasonable assurance that the answers it gets from the kernel are accurate. So a logical point of attack is the bootloader. Compromise the bootloader, and then you can load the kernel into memory and alter the kernel in memory. And then do whatsoever you will.
But even if your bootloader, kernel, and drivers are safe, this does nothing for userspace, like infections via Web browser. There are plenty of meaty morsels for malware to munch in userspace, and anti-malware software is never 100 percent.
Despite all the questions about its safety and actual security benefits, Microsoft requires, as a condition of receiving the official Windows 8 certification, that hardware vendors enable UEFI Secure Boot by default on client systems. They may use their own signing keys, or Microsoft’s. There are financial incentives to getting that official certification, so they’ll all do it. Windows 8 will boot without Secure Boot, and it will install on legacy hardware. But later this year, as the new OEM Windows 8 PCs enter the market, they’re going to ship with UEFI Secure Boot turned on. So everyone who doesn’t want to hassle with Secure Boot will be forced to. Originally Microsoft did not even want a disable option, or to allow users to use their own keys and certificate authorities, but they changed their minds for x86 hardware.
Fedora and Red Hat, wanting to keep their users’ options open, have chosen to pay the $99 fee to be signed with Microsoft’s keys. This will allow Fedora 18 users to use Secure Boot-encumbered systems without disabling it, and eventually Red Hat Enterprise Linux as well. Other distributions are still figuring out what to do.
Implementing Secure Boot for Linux has a number of technical and GPL hurdles, which Matthew Garrett describes in Why UEFI secure boot is difficult for Linux. Executive summary: It means trading ease of use and flexibility for what I think are dubious benefits.
Turning it Off– Except on ARM
How to turn it off on your x86 device? That will depend entirely on the hardware vendor’s implementation. Users will have to enter their UEFI interfaces and hunt down the Secure Boot control, which could be called anything and buried anywhere. I have been unimpressed with the quality control that went into the PC BIOS for all these years, so who knows what fun awaits us in messing with UEFI firmware settings.
ARM hardware is another story– Secure Boot is mandatory and cannot be disabled. (See page 122 of the Windows 8 hardware certification.)
More Security? Really.
To deliver some actual security, Secure Boot needs a bulletproof pre-boot environment, and a trusted, secure certificate authority and signing keys. So the second big question, after “Bulletproof? What’s that?” is whose CA and keys? Microsoft already has a CA infrastructure in place for signing drivers.
But haven’t we learned that the root CAs are vulnerable? How many times has Verisign been compromised? Bruce Schneier calls the certificate system “completely broken.” Who hosts Microsoft’s CA? Verisign. Have we already forgotten the Flame malware that spoofs Microsoft’s own CA, takes over Windows Update, and fools Windows computers believing that the malware they’re installing is genuine trusted signed binaries?
To borrow Bruce Schneier’s wonderful phrase, I think this just another piece of security theater that will inconvenience many and benefit no one. Except for whatever value is derived from forcing purchasers of new hardware to be Secure Boot beta testers, and to once again dance to Microsoft’s tune.
Additional References
Making UEFI Secure Boot Work With Open Platforms, a good and sensible proposal from the Linux Foundation.
Digital Certificate Authority Hacked, Dozens Of Phony Digital Certificates Issued
EFI and Linux: the future is here, and it’s awful – Matthew Garrett
Sam Varghese asks why does the industry, all full of heavyweights like IBM, Novell, Red Hat, and HP, still let Microsoft call the shots?
Unified Extensible Firmware Interface on the Arch Linux Wiki is a nice UEFI howto.
UEFI Secure Boot, Red Hat’s announcement of support for Microsoft’s key registration scheme for booting Red Hat on Windows 8 hardware.
Gentoo Wiki on UEFI kernel and bootloader configuration.
Booting Linux natively on a UEFI system (without BIOS CSM) using GRUB2 from the Ubuntu Wiki.
Coreboot (formerly LinuxBIOS) Supported Motherboards
