It’s AdamW Essay Time again! If you’re looking for something short and snappy, look elsewhere.
Kamil Paral kindly informs me I’m a chronic sufferer of Graphomania. Always nice to know what’s wrong with you.
You’ve probably read a lot of stuff on the internet about UEFI. Here is something important you should understand: 95% of it was probably garbage. If you think you know about UEFI, and you derived your knowledge anywhere other than the UEFI specifications, mjg59′s blog or one of a few other vaguely reliable locations/people – Rod Smith, or Peter Jones, or Chris Murphy, or the documentation of the relatively few OSes whose developers actually know what the hell they’re doing with UEFI – what you think you know is likely a toxic mix of misunderstandings, misconceptions, half-truths, propaganda and downright lies. So you should probably forget it all.
Good, now we’ve got that out of the way. What I mostly want to talk about is bootloading, because that’s the bit of firmware that matters most to most people, and the bit news sites are always banging on about and wildly misunderstanding.
Terminology
First, let’s get some terminology out of the way. Both BIOS and UEFI are types of firmware for computers. BIOS-style firmware is (mostly) only ever found on IBM PC compatible computers. UEFI is meant to be more generic, and can be found on systems which are not in the ‘IBM PC compatible’ class.
You do not have a ‘UEFI BIOS’. No-one has a ‘UEFI BIOS’. Please don’t ever say ‘UEFI BIOS’. BIOS is not a generic term for all PC firmware, it is a particular type of PC firmware. Your computer has a firmware. If it’s an IBM PC compatible computer, it’s almost certainly either a BIOS or a UEFI firmware. If you’re running Coreboot, congratulations, Mr./Ms. Exception. You may be proud of yourself.
Secure Boot is not the same thing as UEFI. Do not ever use those terms interchangeably. Secure Boot is a single effectively optional element of the UEFI specification, which was added in version 2.2 of the UEFI specification. We will talk about precisely what it is later, but for now, just remember it is not the same thing about UEFI. You need to understand what Secure Boot is, and what UEFI is, and which of the two you are actually talking about at any given time. We’ll talk about UEFI first, and then we’ll talk about Secure Boot as an ‘extension’ to UEFI, because that’s basically what it is.
Bonus Historical Note: UEFI was not invented by, is not controlled by, and has never been controlled by Microsoft. Its predecessor and basis, EFI, was developed and published by Intel. UEFI is managed by the UEFI Forum. Microsoft is a member of the UEFI forum. So is Red Hat, and so is Apple, and so is just about every major PC manufacturer, Intel (obviously), AMD, and a laundry list of other major and minor hardware, software and firmware companies and organizations. It is a broad consensus specification, with all the messiness that entails, some of which we’ll talk about specifically later. It is no one company’s Evil Vehicle Of Evilness.
References
If you really want to understand UEFI, it’s a really good idea to go and read the UEFI specification. You can do this. It’s very easy. You don’t have to pay anyone any money. I am not going to tell you that reading it will be the most fun you’ve ever had, because it won’t. But it won’t be a waste of your time. You can find it right here on the official UEFI site. You have to check a couple of boxes, but you are not signing your soul away to Satan, or anything. It’s fine. As I write this, the current version of the spec is 2.4 Errata A, and that’s the version this post is written with regard to.
There is no BIOS specification. BIOS is a de facto standard – it works the way it worked on actual IBM PCs, in the 1980s. That’s kind of one of the reasons UEFI exists.
Now, to keep things simple, let’s consider two worlds. One is the world of IBM PC compatible computers – hereafter referred to just as PCs – before UEFI and GPT (we’ll come to GPT) existed. This is the world a lot of you are probably familiar with and may understand quite well. Let’s talk about how booting works on PCs with BIOS firmware.
BIOS booting
It works, in fact, in a very, very simple way. On your bog-standard old-skool BIOS PC, you have one or more disks which have an MBR. The MBR is another de facto standard; basically, the very start of the disk describes the partitions on the disk in a particular format, and contains a ‘boot loader’, a very small piece of code that a BIOS firmware knows how to execute, whose job it is to boot the operating system(s). (Modern bootloaders frequently are much bigger than can be contained in the MBR space and have to use a multi-stage design where the bit in the MBR just knows how to load the next stage from somewhere else, but that’s not important to us right now).
All a BIOS firmware knows, in the context of booting the system, is what disks the system contains. You, the owner of this BIOS-based computer, can tell the BIOS firmware which disk you want it to boot the system from. The firmware has no knowledge of anything beyond that. It executes the bootloader it finds in the MBR of the specified disk, and that’s it. The firmware is no longer involved in booting.
In the BIOS world, absolutely all forms of multi-booting are handled above the firmware layer. The firmware layer doesn’t really know what a bootloader is, or what an operating system is. Hell, it doesn’t know what a partition is. All it can do is run the boot loader from a disk’s MBR.
UEFI booting: background
OK, so we have our background, the BIOS world. Now let’s look at how booting works on a UEFI system. Even if you don’t grasp the details of this post, grasp this: it is completely different. Completely and utterly different from how BIOS booting works. You cannot apply any of your understanding of BIOS booting to native UEFI booting. You cannot make a little tweak to a system designed for the world of BIOS booting and apply it to native UEFI booting. You need to understand that it is a completely different world.
Here’s another important thing to understand: many UEFI firmwares implement some kind of BIOS compatibility mode, sometimes referred to as a CSM. Many UEFI firmwares can boot a system just like a BIOS firmware would – they can look for an MBR on a disk, and execute the boot loader from that MBR, and leave everything subsequently up to that bootloader. People sometimes incorrectly refer to using this feature as ‘disabling UEFI’, which is linguistically nonsensical. You cannot ‘disable’ your system’s firmware. It’s just a stupid term. Don’t use it, but understand what people really mean when they say it. They are talking about using a UEFI firmware’s ability to boot the system ‘BIOS-style’ rather than native UEFI style.
What I’m going to describe is native UEFI booting. If you have a UEFI-based system whose firmware has the BIOS compatibility feature, and you decide to use it, and you apply this decision consistently, then as far as booting is concerned, you can pretend your system is BIOS-based, and just do everything the way you did with BIOS-style booting. If you’re going to do this, though, just make sure you do apply it consistently. I really can’t recommend strongly enough that you do not attempt to mix UEFI-native and BIOS-compatible booting of permanently-installed operating systems on the same computer, and especially not on the same disk. It is a terrible terrible idea and will cause you heartache and pain. If you decide to do it, don’t come crying to me.
For the sake of sanity, I am going to assume the use of disks with a GPT partition table, and EFI FAT32 EFI system partitions. Depending on how deep you’re going to dive into this stuff you may find out that it’s not strictly speaking the case that you can always assume you’ll be dealing with GPT disks and EFI FAT32 ESPs when dealing with UEFI native boot, but the UEFI specification is quite strongly tied to GPT disks and EFI FAT32 ESPs, and this is what you’ll be dealing with in 99% of cases. Unless you’re dealing with Macs, and quite frankly, screw Macs.
UEFI native booting: how it actually works, part 1 (“boot this disk”)
OK, with that out of the way, let’s get to the meat. This is how native UEFI booting actually works. It’s probably helpful to go into this with a bit of high-level background.
UEFI provides much more infrastructure at the firmware level for handling system boot. It’s nowhere near as simple as BIOS. Unlike BIOS, UEFI certainly does understand, to varying degrees, the concepts of ‘disk partitions’ and ‘bootloaders’ and ‘operating systems’. It’s useful to think of UEFI as attempting to provide a framework for handling operating system at the firmware level.
The UEFI spec defines something called the UEFI boot manager. (Linux distributions contain a tool called efibootmgr which is used to manipulate the configuration of the UEFI boot manager). As a sample of what you can expect to find if you do read the UEFI spec, it defines the UEFI boot manager thusly:
“The UEFI boot manager is a firmware policy engine that can be configured by modifying architecturally defined global NVRAM variables. The boot manager will attempt to load UEFI drivers and UEFI applications (including UEFI OS boot loaders) in an order defined by the global NVRAM variables.”
Well, that’s that cleared up, let’s move on. 
No, not really. Let’s translate that to Human. With only a reasonable degree of simplification, you can think of the UEFI boot manager as being a boot menu. With a BIOS firmware, your firmware level ‘boot menu’ is, necessarily, the disks connected to the system at boot time – no more, no less. This is not true with a UEFI firmware.
There is a UEFI boot mechanism which works in essence quite similarly to BIOS booting: it just boots from a given disk by looking in a standard location for some bootloader code. Not just in BIOS compatibility mode (see above), but in UEFI native mode. This isn’t meant to be used for permanent operating system installations, however. It’s meant as a fallback, and for booting ‘transient’ things, usually on hotpluggable disks – things like live images and operating system install media, where it must be possible to simply connect it to a computer and boot from it, with no special configuration. Depending on your firmware (as we’ll see later, the spec unfortunately does not define the user interface for any of this stuff), you may have the ability to override the default boot configuration and ask the firmware to boot any specific disk connected to the system using this ‘fallback’ method, or your firmware may not let you do this but have it configured sensibly so that it tries to boot any hotplugged drives using this method before it tries to boot any permanently installed operating systems etc, or you may have an insane firmware that does things really badly and makes it very hard to boot from a ‘transient’ medium like this.
What the firmware will actually do when trying to boot in this way is reasonably simple. The disk must have an EFI system partition. An ESP is basically just a partition formatted as FAT12, FAT16 or FAT32, with a particular partition type (this is another simplification). The firmware will look through each partition on the disk that qualifies as an ESP in the order they exist on the disk. Within the ESP, it will look for a file with a specific name and location. On an x86-64 PC, it will look for the file \EFI\BOOT\EFI\BOOTx64.EFI. What it actually looks for is \EFI\BOOT\EFI\BOOT{machine type short-name}.EFI – ‘x64′ is the “machine type short-name” for x86-64 PCs. The other possibilities are BOOTIA32.EFI (x86-32), BOOTIA64.EFI (Itanium), BOOTARM.EFI (AArch32 – that is, 32-bit ARM) and BOOTAA64.EFI (AArch64 – that is, 64-bit ARM). It will then execute this file (obviously, the file needs to be in the executable format defined in the UEFI specification).
This whole mechanism is not designed for booting permanently-installed OSes. It’s more designed for booting hotpluggable, device-agnostic media, like live images and OS install media. And this is indeed what it’s usually used for. If you look at a UEFI-capable live or install medium for a Linux distribution or other OS, you’ll find it contains a FAT-formatted partition at or near the start of the device, with a particular partition type – utilities like gparted and recent versions of fdisk will identify this as an EFI system partition – and with a \EFI\BOOT directory with at least one of the specially-named files above. When you boot a Fedora live or install medium in UEFI-native mode, this is the mechanism that is used. The BOOTx64.EFI (or whatever) file handles the rest of the boot process from there, booting the actual operating system contained on the medium.
UEFI native booting: how it actually works, part 2 (“boot this operating system (or other particular thing)”)
That’s not the UEFI boot mechanism that’s intended to be used (or, in most cases, actually used) for booting installed operating systems, though. Remember I said UEFI provides a firmware-level infrastructure for selecting particular ‘things’ – not just a particular disk – to boot? Remember I talked about the UEFI boot manager? Well, here we go.
By adding an entry to the UEFI boot manager, the firmware can also be instructed to boot a particular ‘thing’.
If you actually have a UEFI-native installation of Fedora or some other Linux distribution, boot it up, and run sudo efibootmgr -v. What you’ll get will look roughly like this:
This is a nice clean example I stole and slightly tweaked from the Fedora forums. We can see a few things going on here.
The first line tells you which of the ‘boot menu’ entries you are currently booted from. The second is pretty obvious (if the firmware presents a boot menu-like interface to the UEFI boot manager, that’s the timeout before it goes ahead and boots the default entry). The BootOrder is the order in which the entries in the list will be tried. The rest of the output shows the actual boot entries.
Boot0000, Boot0001 and Boot0004 in this example are actually BIOS compatibility mode entries, not UEFI native entries. They have not been added to the UEFI boot manager configuration by any external agency, but produced by the firmware itself – this is a pretty common way for a UEFI firmware to implement BIOS compatibility booting, by generating UEFI boot manager entries that trigger a BIOS-compatible boot of a given device. How they present this to the user is a different question, as we’ll see later. Whether you see any of these entries or not will depend on your particular firmware, and its configuration. You may also see similar entries without BIOS – these would be entries for the “just UEFI-native boot this disk” method described above. However, we’re not primarily interested in either of those kinds of entry right now.
Boot0002 and Boot0003 are what we’re interested in. Boot0002 is a boot entry produced by a UEFI-native Fedora installation. Boot0003 is a boot entry produced by a UEFI-native OpenSUSE installation. As you can see, these are really pretty simple: as you may be able to tell, all they’re saying is “load this file from this partition”. The partition is the HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) bit: that’s referring to a specific partition. The file is the File(\EFI\opensuse\grubx64.efi) bit: that just means “load the file in this location on the partition we just described”.
There’s actually a huge range of possibilities for these entries, that makes up rather a large part of the complexity of the UEFI spec all by itself. If you’re reading the spec, pour yourself an extremely large shot of gin and turn to the EFI_DEVICE_PATH_PROTOCOL section, but note that this is a generic protocol that’s used for other things than booting – it’s UEFI’s Official Way Of Identifying Devices For All Purposes, used for boot manager entries but also for all sorts of other purposes. Not every possible EFI device path makes sense as a UEFI boot manager entry, for obvious reasons (you’re probably not going to get too far trying to boot from your video adapter). But you can certainly have an entry that points to, say, a PXE server, not a disk partition.
Anyway, the important thing to realize is that what these entries are doing is telling the firmware ‘look on this partition for this file, and execute it’. This is the mechanism the UEFI spec provides for operating systems to make themselves available for booting: the operating system is intended to install a bootloader which loads the OS kernel and so on to an EFI system partition, and add an entry to the UEFI boot manager configuration with a name – obviously, this will be derived from the operating system’s name – and the location of the bootloader (in EFI executable format) that is intended for loading that operating system.
Linux distributions use the efibootmgr entry to deal with the UEFI boot manager. What a Linux distribution actually does, so far as bootloading is concerned, when you do a UEFI native install of that operating system is really pretty simple: it creates an EFI system partition if there is not one, installs an EFI boot loader with an appropriate configuration – often grub2-efi, but there are others – into a correct path in the EFI system partition, and calls efibootmgr to add an appropriately-named UEFI boot manager entry pointing to its boot loader.
You can use efibootmgr to add, delete and modify entries in the UEFI boot manager configuration, and actually do quite a lot of other stuff with it too. You can change the boot order. You can tell it to boot some particular entry in the list on the next boot, instead of using the BootOrder list. There are tools for Windows that can do this stuff from Windows, too.
So to recap:
Your UEFI firmware contains something very like what you think of as a boot menu.
You can query its configuration with efibootmgr -v, from any UEFI-native boot of a Linux OS, and also change its configuration with efibootmgr (see the man page for details).
This ‘boot menu’ can contain entries that say ‘boot this disk in BIOS compatibility mode’, ‘boot this disk in UEFI native mode’ (which will use the ‘look for BOOT(something).EFI’ method described above), or ‘boot the specific EFI format executable at this specific location’.
The nice, clean design that the UEFI spec is trying to imply is that all operating systems should install a bootloader of their own to a shared EFI system partition, add entries to this ‘boot menu’ that point to themselves, and butt out from trying to take control of booting anything else.
Implications and Complications
So, that’s how UEFI booting works, at least a reasonable approximation. When I describe it like that, it almost all makes sense, right?
However, all is not sweetness and light. There are problems. There always are.
Attentive readers may have noticed that I’ve talked about the UEFI spec providing a mechanism. This is accurate, and important. As the UEFI spec is a ‘broad consensus’ sort of thing, one of its major shortcomings (looked at from a particular perspective) is that it’s nowhere near prescriptive enough.
If you read the UEFI spec critically, its basic approach is to define a set of functions that UEFI compliant firmwares must support. What it doesn’t do a lot of at all is strictly requiring things to be done in any particular way, or not done in any particular way.
So: the spec says that a system firmware must do all the stuff I’ve described above, in order to be considered a UEFI-compliant firmware. The spec, however, doesn’t talk about what operating systems ‘should’ or ‘must’ do at all, and it doesn’t say that firmwares must not support (or no-one may expect them to support, or whatever)…anything at all. If you’re making a UEFI firmware, in other words, you have to support GPT formatted disks, and FAT-formatted EFI system partitions, and you must read UEFI boot manager entries in the standard format, and you must do this and that and the other – but you can also do any other crap you like.
It’s pretty easy to read certain implications from the spec – it carefully sets up this nice mechanism for handling OS (or other ‘bootable thing’) selection at the firmware level, for instance, with the clear implication “hey, it’d be great if all OSes were written to this mechanism”. But the UEFI spec doesn’t require that, and neither does any other widely-respected specification.
So, what happens in the real world is that we wind up with really dumb crap. Apple, for instance, ships at least some Macs with HFS+ EFI system partitions. The spec says a UEFI-compliant firmware must support FAT32 EFI system partitions, but it doesn’t say it can’t support ESPs with other filesystems. The world would pretty clearly be a better place if everyone just damn well agreed on an EFI system partition format, but Apple is Apple and we can’t have nice things, so Apple went right ahead and wrote firmwares that support FAT32 ESPs, sure, but also support HFS+ ESPs, and shipped HFS+ ESPs. So now everyone else has to deal with HFS+ ESPs. The UEFI spec doesn’t say anything about HFS+ ESPs, but they exist, no-one can tell Apple that they shouldn’t exist, and now we have a choice of just ignoring Macs, or dealing with them.
There are various similar incredibly annoying corner cases we’ve come across. The entire UEFI spec was clearly conceived and written with the general expectation that you’d format your disks as GPT unless you have a really very good reason not to, but it doesn’t actually require this. So of course, some jackass went and shipped systems with UEFI firmwares and UEFI-native installations of Windows…on disks formatted with MBRs (sometimes referred to as ‘ms-dos disk labelling’ or similar). This is really goddamn infuriating, but now anyone who writes an OS installer gets to either tell those systems to get stuffed, or try and deal with the possibility that it might wind up dealing with an MBR-formatted disk containing an existing UEFI-native operating system.
The other infuriating thing about the UEFI spec is that it does quite a good job of defining that this whole mechanism must exist, but it explicitly refrains from making almost any requirements as to a user interface for it. So a UEFI compliant firmware must implement all this UEFI boot manager stuff, but it is not required to present it to the user in any particular way, or indeed at all.
Firmware engineers being firmware engineers, we have naturally seen UEFI firmwares that present the whole UEFI boot manager mechanism to the user in incredibly, psychotically stupid ways, or just don’t present it at all. You can usually rely on the firmware at least allowing the user to (try to) boot any given disk in UEFI-native or BIOS-compatibility mode, and choose to boot any specific entry from the UEFI boot manager list, but not always.
So if a couple of software companies write OSes to behave ‘nicely’ according to the conventions the spec is clearly designed to back, and install EFI boot loaders and define EFI boot manager entries with nice clear names – like, oh say, “Fedora” and “Windows” – they are implicitly relying on the firmware to then give the user some kind of sane interface somewhere relatively discoverable that lets them choose to boot “Windows” or “Fedora”. You’d think this would be pretty simple, but no, we can’t have nice things; we’ve seen firmwares where this choice is buried under sixteen levels of sub-menus and labelled completely insanely, or where it’s simply not offered at all. Because the UEFI spec doesn’t actually set any standards for this.
To be fair, we could do somewhat more at the OS level. We could present all those neat efibootmgr capabilities rather more obviously – we can use that ‘don’t respect BootOrder on the next boot, but instead boot this‘ capability, for instance, and have ‘Reboot to Windows’ as an option. It’d be kinda nice if someone looked at exposing all this functionality somewhere more obvious than efibootmgr. Windows 8 systems do use this, to some extent – you can reboot your system to the firmware UI from the Windows 8 settings menus, for instance. But still.
All this is really incredibly frustrating, because UEFI is so close to making things really a lot better. The BIOS approach doesn’t provide any kind of convention or standard for multibooting at all – it has to be handled entirely above the firmware level. We (the industry) could have come up with some sort of convention for handling multiboot, but we never did, so it just became a multiple-decade epic fail, where each operating system came up with its own approach and lots of people wrote their own bootloaders which tried to subsume all the operating systems and all the operating systems and independent bootloaders merrily fought like cats in a sack. I mean, pre-UEFI multibooting is such a clusterf**k it’s not even worth going into, it’s broken sixteen ways from Sunday by definition.
If UEFI – or a spec built on top of it – had just mandated that everybody follow the conventions UEFI carefully establishes, and mandated that firmwares provide a sensible user interface, the win would have been epic. But it doesn’t, so it’s entirely possible that in a UEFI world things will be even worse than they were in the BIOS world. If many more firmwares show up that don’t present a good UI for the UEFI boot manager mechanism, what could happen is that OS vendors give up on the UEFI boot manager mechanism (or decide to support it and alternatives, because choice!) and just reinvent the entire goddamn nightmare of BIOS multibooting on top of UEFI – and we’ll all have to deal with all of that, plus the added complication of the UEFI boot manager layer. You’ll have multiple bootloaders fighting to load multiple operating systems all on top of the whole UEFI boot manager mechanism which is just throwing a whole bunch of other variables into the equation.
This is not a prospect filling the mind of anyone who’s had to think about it with joy.
Still, it’s important to recognize that the sins of UEFI in this area are sins of omission – they are not sins of commission, and they’re not really the result of evil intent on anyone’s part. The entity you should really be angry with if you have an idiotic system firmware that doesn’t give you good access to the UEFI boot manager mechanism is not the UEFI forum, or Microsoft, and it certainly isn’t Fedora and even more certainly isn’t me ;). The entity you should be angry at is your system/motherboard manufacturer and the goddamn incompetents they hired to write the firmware, because the UEFI spec makes it really damn clear to anyone with two brain cells to rub together that it would be a very good idea to provide some kind of useful user interface to the UEFI boot manager, and any firmware which doesn’t do so is crap code by definition. Yes, the UEFI forum should’ve realized that firmware engineers couldn’t code their way out of a goddamned paper bag and just ordered them to do so, but still, it’s ultimately the firmware engineers who should be lined up against the nearest wall.
Wait, we can simplify that. “Any firmware is crap code”. Usually pretty accurate.
Secure Boot
So now we come, finally, to Secure Boot.
Secure Boot is not magic. It’s not complicated. OK, that’s a lie, it’s incredibly complicated, but the theory isn’t very complicated. And no, Secure Boot itself is not evil. I am entirely comfortable stating this as a fact, and you should be too, unless you think GPG is evil.
Secure Boot is defined in chapter 28 of the UEFI spec (2.4a, anyway). It’s actually a pretty clever mechanism. But what it does can be described very, very simply. It says that the firmware can contain a set of signatures, and refuse to run any EFI executable which is not signed with one of those signatures.
That’s it. Well, no, it really isn’t, but that’s a reasonably acceptable simplification. Security is hard, so there are all kinds of wibbly bits to implementing a really secure bootchain using Secure Boot, and mjg59 can tell you all about them, or you can pour another large shot of gin and read the whole of chapter 28. But that’s the basic idea.
Using public key cryptography to verify the integrity of something is hardly a radical or evil concept. Pretty much all Linux distributions depend on it – we sign our packages and have our package managers go AWOOGA AWOOGA if you try to install a package which isn’t signed with one of our keys. This isn’t us being evil, and I don’t think anyone’s ever accused an OS of being evil for using public key cryptographic signing to establish trust in this way. Secure Boot is literally this exact same perfectly widely accepted mechanism, applied to the boot chain. Yet because a bunch of journalists wildly grasped the wrong end of the stick, it’s widely considered to be slightly more evil than Hitler.
Secure Boot, as defined in the UEFI spec, says nothing at all about what the keys the firmware trusts should be, or where they should come from. I’m not going to go into all the goddamn details, because it gets stultifyingly boring and this post is too long already. But the executive summary is that the spec is utterly and entirely about defining a mechanism for doing cryptographic verification of a boot chain. It does not really even consider any kind of icky questions about the policy for doing so. It does nothing evil. It is as flexible as it could reasonably be, and takes care to allow for all the mechanisms involved to be configurable at multiple levels. The word ‘Microsoft’ is not mentioned. It is not in any way, shape, or form a secret agenda for Microsoft’s domination of the world. If you doubt this, at the very bloody least, go and read it. I’ve given you all the necessary pointers. There is literally not a single legitimate reason I can think of for anyone to be angry with the idea “hey, it’d be neat if there was a mechanism for optional cryptographic verification of bootloader code in this firmware specification”. None. Not one.
Secure Boot in the real world
Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – but about specific implementations of Secure Boot in the real world.
The only one we really care about is Secure Boot as it’s implemented on PCs shipped with Microsoft Windows 8 or higher pre-installed.
Microsoft has these things called the Windows Hardware Certification Requirements. There they are. They are not Top Secret, Eyes Only, You Will Be Fed To Bill Gates’ Sharks After Reading – they’re right there on the Internet for anyone to read.
If you want to get cheap volume licenses of Windows from Microsoft to pre-install on your computers and have a nice “reassuring” ‘Microsoft Approved!’ sticker or whatever on the case, you have to comply with these requirements. That’s all the force they have: they are not actually a part of the law of the United States or any other country, whatever some people seem to believe. Bill Gates cannot feed you to his sharks if you sell a PC that doesn’t comply with these requirements, so long as you don’t want a cheap copy of Windows to pre-install and a nice sticker. There is literally no requirement for a PC sold outside the Microsoft licensing program to configure Secure Boot in any particular way, or include Secure Boot at all. A PC that claims to have a UEFI 2.2 or later compliant firmware must implement Secure Boot, but can ship with it configured in literally absolutely any way it pleases (including turned off).
If you’re going to have very loud opinions about Secure Boot, you have zero excuse for not going and reading the Microsoft certification requirements. Right now. I’ll wait. You can search for “Secure Boot” to get to the relevant bit. It starts at “System.Fundamentals.Firmware.UEFISecureBoot”.
You should read it. But here is a summary of what it says.
Computers complying with the requirements must:
Ship with Secure Boot turned on (except for servers)
Have Microsoft’s key in the list of keys they trust
Disable BIOS compatibility mode when Secure Boot is enabled (actually the UEFI spec requires this too, if I read it correctly)
Support signature blacklisting
x86 computers complying with the requirements must additionally:
Allow a physically present person to disable Secure Boot
Allow a physically present person to enable Custom Mode, and modify the list of keys the firmware trusts
ARM computers complying with the requirements must additionally:
NOT allow a physically present person to disable Secure Boot
NOT allow a physically present person to enable Custom Mode, and modify the list of keys the firmware trusts
Yes. You read that correctly. The Microsoft certification requirements, for x86 machines, explicitly require implementers to give a physically present user complete control over Secure Boot – turn it off, or completely control the list of keys it trusts. Another important note here is that while the certification requirements state that the out-of-the-box list of trusted keys must include Microsoft’s key, they don’t say, for e.g., that it must not include any other keys. The requirements explicitly and intentionally allow for the system to ship with any number of other trusted keys, too.
These requirements aren’t present entirely out of the goodness of Microsoft’s heart, or anything – they’re present in large part because other people explained to Microsoft that if they weren’t present, it’d have a hell of a lawsuit on its hands1 – but they are present. Anyone who actually understands UEFI and Secure Boot cannot possibly read the requirements any other way, they are extremely clear and unambiguous. They both clearly intend to and succeed in ensuring the owner of a certified system has complete control over Secure Boot.
If you have an x86 system that claims to be Windows certified but does not allow you to disable Secure Boot, it is in direct violation of the certification requirements, and you should certainly complain very loudly to someone. If a lot of these systems exist then we clearly have a problem and it might be time for that giant lawsuit, but so far I’m not aware of this being the case. All the x86-based, Windows-certified systems I’ve seen have had the ‘disable Secure Boot’ option in their firmwares.
Now, for ARM machines, the requirements are significantly more evil: they state exactly the opposite, that it must not be possible to disable Secure Boot and it must not be possible for the system owner to change the trusted keys. This is bad and wrong. It makes Microsoft-certified ARM systems into a closed shop. But it’s worth noting it’s no more bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders.
If you’re planning to buy a Microsoft-certified ARM device, be aware of this, and be aware that you will not be in control of what you can boot on it. If you don’t like this, don’t buy one. But also don’t buy an iDevice, or an Android device with a locked bootloader (you can buy Android devices with unlocked or unlockable bootloaders, still, but you have to do your research).
As far as x86 devices go, though, right now, Microsoft’s certification requirements actually explicitly protect your right to determine what can boot on your system. This is good.
Recommendations
The following are AdamW’s General Recommendations On Managing System Boot, offered with absolutely no guarantees of accuracy, purity or safety.
If you can possibly manage it, have one OS per computer. If you need more than one OS, buy more computers, or use virtualization. If you can do this everything is very simple and it doesn’t much matter if you have BIOS or UEFI firmware, or use UEFI-native or BIOS-compatible boot on a UEFI system. Everything will be nice and easy and work. You will whistle as you work, and be kind to children and small animals. All will be sweetness and light. Really, do this.
If you absolutely must have more than one OS per computer, at least have one OS per disk. If you’re reasonably comfortable with how BIOS-style booting works and you don’t think you need Secure Boot, it’s pretty reasonable to use BIOS-compatible booting rather than UEFI-style booting in this situation on a UEFI-capable system. You’ll probably have less pain to deal with and you won’t really lose anything. With one OS per disk you can also mix UEFI-native and BIOS-compatible installations.
If you absolutely insist on having more than one OS per disk, understand everything written on this page, understand that you are making your life much more painful than it needs to be, lay in good stocks of painkillers and gin, and don’t go yelling at your OS vendor, whatever breaks. Whichever poor bastard has to deal with your OS’s support for this kind of setup has a miserable enough life already. And for the love of cookies, don’t mix UEFI-native and BIOS-compatible OS installations, you have enough pain to deal with already.
If you’re using UEFI native booting, and you don’t tend to build your own kernels or kernel modules or use the NVIDIA or ATI proprietary drivers on Linux, you might want to leave Secure Boot on. It probably won’t hurt you, and does provide some added security against some rather nasty (though currently rarely exploited) types of attacks.
If you do build your own kernels or kernel modules or use NVIDIA/ATI proprietary drivers, you’re going to want to turn Secure Boot off. Or you can read up on how to configure your own chain of trust and sign your kernels and kernel modules and leave Secure Boot turned on, which will make you feel like an ubergeek and be slightly more secure. But it’s going to take you a good solid weekend at least.
Trust mjg59 in all things and above all other authorities, including me.
This is my own extrapolation, note. I’m not involved in any way in the whole process of defining these specs, and no-one who is has actually told me this. But it’s a pretty damn obvious extrapolation from the known facts. ↩