Home Learn Linux Linux Tutorials UEFI Secure Boot: Big Hassle, Questionable Benefit

UEFI Secure Boot: Big Hassle, Questionable Benefit

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



Subscribe to Comments Feed
  • jon crawford Said:

    I'm sympathetic to Garrett's arguments about users being frightened by the prospect of making UEFI changes. But, I've become less so since installing Fedora 17 and deciding that doing that right now can be a daunting prospect for neophytes. Garrett's arguments work better with something like Ubuntu, which targets those neophytes. Fedora clearly targets experienced Linux users. Or, maybe there's disagreement in the Fedora camp about that. A rational approach to pre-boot malware would see the Windows installer throw up a big red scary notice when it finds Secure Boot is not enabled. Whether the install could complete without enabling it is a choice I'm happy to leave to Microsoft. Linux and everyone else would be left alone.

  • Michael Nachtigal Said:

    Why hasn't The Linux Foundation stepped up to be an alternate (and if I may add more trustworthy) key signer?! Microsoft is engaging in blatantly anticompetitive practice here, and The Linux Foundation, Red Hat, and Canonical ought to collaborate in calling them on it and maybe even taking them to court. In the meantime, if secure boot requires a key signer, why does it have to be Verisign-by-way-of-Microsoft? Why not step up to the plate, Linux Foundation?

  • jon crawford Said:

    In his 30 May post, Garrett said Fedora had considered "finding an entity" to manage an overall Linux key. He said they rejected that approach because it would cost "millions" to keep the key secure and to validate the people applying for keys. I have no way of determining the cost of validating key applicants, but I can see why an organization like the Linux Foundation wouldn't jump at the chance. The effort would need to be financed, as well. Garrett adds that "nobody was jumping at the opportunity to volunteer", which suggests Fedora pitched the idea to someone. Perhaps they already talked to the Linux Foundation. However, since we are talking about a one-time $99 fee per distribution, I don't see the cost of dealing with Verisign to be an issue for any distribution backed by any kind of organization at all. For singleton distress and such, that's obviously a different matter. Perhaps the Linux Foundation might offer to fund those, after creating some procedures to avoid getting ripped off.

  • stefan Said:

    " 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.".... so it must be possible to write our own UEFI-linux-firmware with like dd-wrt? Or with some quickbooting network enabled environment like xpud? Or have I missed some point? Can consumers put their own UEFI-firmware on these new PCs? Thanks for information about that! Greetings from really hot Vienna, Austria (36 Grad Celsius)! stefan

  • Leslie Satenstein Said:

    UEFI will die by Microsoft hands. Once there is a download patch that is corrupted, or the bootmgr is corrupted, what will it take to uninstall and reinstall. The UEFI is a way as well, to keep dual booting of Linux and Windows apart. Presumeably with UEFI, all Windows I/O will be encrypted, leading to more problems when a technician has to recover data from a partially damaged disk. UEFI is an idea that will cause a lot of pain for Microsoft and for everyone else

  • Stephen Samuel Said:

    The other question is: Just what percentage of currently active malware would have been prevented by 'secure boot'? I'd be surprised if it was as much as 1%.

  • Renee Marie Jones Said:

    In a just society it would be illegal for a company to "sell" you a product, then use locks to prevent you from exercising your property rights over the product that you now own. It would also be illegal for a company to misrepresent an anti-competition measure like UEFI as a "security" tool, when it is plain to any expert that such a system cannot possibly provide security. These sorts of frauds can only be foisted on the public by a combination of the public's ignorance and the court's corruption.

  • Яаков Said:

    Does an UEFI bios "write home to Mama" in the ЦРУ?

  • Bill Said:

    Has anyone thought of starting a class action against Microsoft for taking control of a home built machine and telling them what they can and cant do with it.

  • Thme Said:

    UEFI(and secure-boot) is a good thing that has potential to be abused like any other. I suppose some manufacturers may make it harder to get around in or alter in any way(such as hiding the disable option in some obscure terminology or something). but there are manufacterers who are known for providing good support to people who tinker and modify their own hardware/software.(example: ASUS motherboards). Developers would require such in many cases where testing is involved so it's not exactly why microsoft would enable secure boot by default. Making it harder to boot other OS's is just a consequential benefit to them out of many other benefits which are legitimate. Even Linus Torvalds like the idea of secure-boot.

  • Stephen Samuel Said:

    There was an email released a few years back where MS executives were looking for a way to modify the boot process to limit the availability of other operating systems (especially Linux). UEFI fulfills that intent, and security is actually a (limited) side effect -- more of an excuse, really. Microsoft's security issues go far beyond the boot process, and UEFI does little to address those core problems.

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board