UEFI boot: how does that actually work, then?
happyassassin.net
happyassassin.net
Before people click on that link and start thinking the author of the article is a damn liar (the link takes one to a menacing "Access Denied" page which prompts users to login or register (which in turn involves filling out a form and possibly paying a large amount of money)), here is a link to free downloads of the specification documents (as PDF files):
http://www.uefi.org/specifications
And by the way, no need to check any boxes at all, just click any of the links and the download should start right away.
So if I download these files, I acknowledge that I may not use the spec to do anything useful with it. It might be better to derive UEFI knowledge from the Tianocore sources, since those come with no strings attached.
> there used to be a thing called BIOS that was dead simple to deal with and did what you want. Now there is a replacement called UEFI that is insanely complicated to deal with and (at least in practice) makes it hard to do what you want.
Is that accurate?
I'd amend your statement to be "There used to be a very limited thing called BIOS, a collection of historical hacks, which only did one thing decently, but not really well. To make matters worse, in all cases but this one, it completely fell apart. There was no consistent tooling, and when it worked, it was non-inspectable black magic even to the most sophisticated power-user. The limitations of BIOS booting caused different OSes to constantly step on each others feet."
UEFI is different, but actually has a design, supports tooling, any OS can work with it seamlessly without fear of collision, and as result it handles all scenarios simple or complex equally well.
As a bonus it can also do a million things BIOS couldn't, like loading a Linux-kernel directly, from acoss the network, without any intermedia-bootloading proxy or iPXE shim.
Now you can actually put your bootloader setup in source-control. I'm not sure why you would do that, but please go ahead and try that with BIOS.
So yeah. UEFI really isn't that complex. It's just different. It just seems more complex because now even regular guys like us can see all the moving parts, where in the past only OS-designers could peek in.
It would have been fully possible to create something better than BIOS without (effectively) creating a new mini MS-DOS inside the machine firmware. The buggy UEFI firmwares some people has had to suffer also lends hand to that argument: A simpler specification would probably have caused people fewer issues.
Sometimes less is more. I suspect UEFI would have been more warmly received had it taken a lower aim. It probably didn't help either that it was initially (wrongfully?) associated with Microsoft, and a hostile anti-Linux takeover of the X86 platform at firmware level.
> 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.
I've dual-booted with multiple OSes per disk with BIOS several times and had no problems at all. So I can't help but get a bad impression of UEFI.
I think this article was written back when you had to setup everything UEFI manually, at least in the Linux-world. I don't think all parts still applies.
These days most of these things should be taken care of automatically for you, by the OS vendor, just like they used to in the BIOS past.
Except now you wont have to mess around with installation-order, custom bootloaders or weird grub-entries. It's all handled natively by UEFI.
It also didn't cover the replacement of the BIOS VGA baseline graphical communication standard with GOP (Graphics Output Protocol) - meaning that your graphics card itself specifically needs to be compatible with UEFI / EFI to even boot.
I'm sad he took a negative stance to Apple in the article. Their implementation (of EFI) is very interesting in the choices they made and it's worth noting the differences (they do not, for instance, provide a graphical configuration choice "boot menu" like most PCs - they only provide visual boot media selection).
Another interesting thing Apple did was, prior to all Windows editions natively booting to UEFI / EFI, they still wanted to provide dual boot support for OS X and Windows on their Intel Macs. But this meant that while OS X was EFI booting and required GPT drives - Windows was BIOS booting and required MBR drives. As such, Apple used a hybrid GPT/MBR format where the partition maps in both were in synchronization and GPT reserved the areas where MBR information was stored on the drive.
Good: No firmware setup UI. Leave the user out of it.
Good: Firmware built-in GUI boot manager that discovers currently bootable OS's dynamically. Plug in an external, an icon appears with an animated reveal. Animation in the f'n firmware built-in boot manager.
Bad: That boot manager hard wires a label "Windows" for any legacy CSM-BIOS installed OS, even if it isn't Windows.
Mixed: Apple's firmware is mainly based on Intel 1.10, with some extensions such as UEFI GOP, and some Apple stuff. It's not a standard UEFI 2.x firmware at all, and it's not documented at all. 3rd party bootloader programs have to have physical access to Macs to poke them with a stick in order to figure out how they work due to Apple's closed nature. So if you care about running open source OS's on Apple hardware, this is probably more "bad" than "mixed".
Very bad: There's a long standing pernicious bug with Disk Utility, on Boot Camp'd drives (OS X + Windows) which permits the user to resize the OS X volume thereby creating a 5th partition: ESP, OS X, New Partition, Apple Boot, Windows. And Apple's tools remove the hybrid MBR, replace it with a protective MBR, and now Windows is unbootable. All without warning. This behavior violates their own proscription against manipulating drives with hybrid MBRs. Technote 2166: "If block 0 contains any other form of MBR, it should refuse to manipulate the disk." Their message boards have hundreds of such complaints. This isn't new, it's been a problem for years, it was bug reported years ago, and Apple basically blamed it on Windows rather than their own tool which actually causes the problem by wiping out the PMBR. https://developer.apple.com/library/mac/technotes/tn2166/_in...
So I'm not a fan of their hybrid MBR hack, even though earlier on it was probably unavoidable. Windows has supported UEFI booting since Vista, but Apple's kinda dragged their feet on supporting UEFI Windows boot until very recently, and I'm not even certain Boot Camp Assistant defaults to this behavior yet.
The the entire OS to BIOS API changed with UEFI. I've seen bugs where the BIOS int 15 ax=E820 memory map does not match the EFI memory map passed to Linux.
All of this to support > 2TB drives.
EFI came to the PC because Apple wasn't interested in starting a 16-bit 8086 programming division, and the rest of the industry followed suit because it was easier than squeezing more things into the 16-bit BIOS. Now that we've got both EFI and GPT widely available, we can have machines that can do things like fetch and install their own firmware updates and we can have sane dual-booting.
It's been done:
http://warfish.github.io/doom-uefi/
Source code is here:
I have recently been learning about OpenBSD. I really like how they have handled all the weirdness associated with PC architecture booting/partitioning. OpenBSD simply ignores it and does everything on top of it. Once you have a partition marked as OpenBSD you are done the architecture specific stuff. Then you go on to do things the OpenBSD way which is the same over all architectures. So when Intel comes up with UUEFI (or whatever) you can continue to ignore the whole mess.
"many" not "all", and the article sticks to that.
Since CSMs are incompatible with Secure Boot (since they can run whatever, without extending the trust chain), I expect them to be on the way out. Same as with the "Secure Boot optional" requirement on x86, by the way, since I guess that the real reason Microsoft added that to their Windows Logo requirements is that their large customers wanted to be sure that they can image Windows 7 onto new machines for a while longer.
Once this kind of legacy is gone for good, Microsoft may tighten the screws there. And since all big Linux vendors support Secure Boot now, that part of the PC landscape won't make many noises either.
The shim loader is an MIT-licensed piece of code that's signed by a Secure Boot CA, typically MS for off-the-shelf x86 hardware. The shim has another public key hard-coded into it, and verifies that the next bootloader (usually GRUB 2) is signed with that key. It works around a couple of issues:
- The turnaround time for getting something signed by MS is slow. Linux distros want to be able to push out a new version of GRUB on their own. So by having the CA sign a shim loader, new versions of the boot loader can be signed with the distro's key alone, which they can automate as much as they want.
- There's some ambiguity over the GPLv3's TiVoization clause, so to avoid any interpretation that MS would have to hand over its own private key, MS won't sign any GPLv3 software directly (like GRUB). The distros think this is a non-issue, and they're happy to sign their own GRUB binaries without imagining they'd have to give up their private keys.
It doesn't change the security model of Secure Boot at all. You're still verifying that someone whose key is in hardware has a trust path to your bootloader. It's just that the trust path is one more step away.
If you want to include your distro's key in the UEFI variable that lists your Secure Boot CA roots, you can do that, and skip the shim. (You probably can't remove MS's key because UEFI drivers are signed with it, but that's a different issue.)
Some distros (notably Ubuntu) have their bootloader willing to boot unsigned kernels, on the grounds that Secure Boot protects UEFI "boot services" (things that run while UEFI still controls the machine, including access to certain UEFI variables like Secure Boot config), but does not protect ring 0. Other distros (Fedora, SuSE, etc.) think that that's nonsense, and Secure Boot obviously protects ring 0. So their bootloader only boots signed kernels, and those kernels, in turn, only load signed kernel modules.
MS has complained about Ubuntu's interpretation, but has so far not shown any signs of forcing Ubuntu to change their practices. (I suspect with no real information that MS is worried that, if they're holding the only CA for PC hardware and they revoke the most popular Linux distro, they're going to be reminded of what antitrust lawsuits feel like.) You can see MS's signing policy here, including a link to the (non-MS) shim:
http://blogs.msdn.com/b/windows_hardware_certification/archi...
- BIOS emulation is not a required by the UEFI spec. You can buy laptops today that are UEFI-only.
Unfortunately, people in the real world use implementations of secure boot, not its specification.
>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.
Post-US vs. Microsoft, MS does not want to be seen to be explicitly violating anti-trust law, which is why in public and on the record, they will say and do nothing wrong. This has actually done a lot of good, because it does shackle their ability to engage in anti-competitive behavior.
It just doesn't shackle it completely, and it means that in order to do it they have to be a bit more creative.
They still wield a large amount of power over the PC market, and manufacturers know this. They still have several ways of opaquely favoring or disfavoring some manufacturers over others. Manufacturers, on the whole, dont't mind being opaquely favored and don't want to be opaquely disfavored and know that crying foul about Microsoft abusing its market power in secret won't do them any favors either.
It's a cut throat market and nobody is going to feel sorry for you as a manufacturer if you died out because you didn't get an Microsoft promotional tie in.
Thus sometimes, all it takes for anti-trust violations to continue and to go unpunished is a nudge and a wink or an off the record conversation between MS and manufacturers, and a decision made by either party that falls in a gray area of legal defensibility.
Here's where it gets evil, and here's the bit you are glossing over:
Secure boot PROVIDES that gray area while maintaining a veneer of respectability.
>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.
Certainly you seem to be able to turn it off in most implementations I've seen, but I haven't seen any that let me add trusted keys myself. Another gray area methinks.
Nor is turning it off particularly easy. I know where it is and what it does, but I know the history behind it.
MOST people draw a blank stare when they look at it and CERTAINLY don't get to the menu and look at it and think "oh, for sure this is the thing that stops me from installing linux".
Oh, and incidentally I've never eer seen a coherent error message caused by secure boot's "protection". Not "you appear to be installing an untrusted OS". Just blank screens and opaque error messages.
Let's say hypothetically that instead of being buried three menus deep, it was a physical switch, with a clear explanation about what it actually does.
Let's say hypothetically that adding a key for secure boot were done using a clean and simple UI that my mother could follow. Flip the switch, plug in a USB key to boot from, menu asks if you want to trust this OS. You say yes and flip the switch back on.
Let's say hypothetically that trying to install an "untrusted" OS gave you a clear error message.
If these were the case (and these things certainly adhere to the spec), I wouldn't have a problem with it either. Let's be realistic, though. It's not that. It was not ever intended to be that. It was not supposed to be used to secure your system, and while Microsoft did just enough to avoid a lawsuit over it, their intentions are crystal clear.
Hardware manufacturers also know what's up, and won't be making it an easy to use feature any time soon.
MS is playing the same game they did pre-DOJ, they're just trying to keep plausible deniability at the same time as greasing all of the right palms. MS pretends not to violate antitrust law. Microsoft contributes to all the right election campaigns. DOJ pretends not to notice that Microsoft's secure boot initiative (if not the spec) is anti-competitive.
>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.
Microsoft is not explicitly breaking the law here. This is indeed good. Let's award them a fucking medal. By the way, I didn't deal drugs today. This is also good.
As for UEFI itself - it reminds me of XML - designed by committee, and yes, strictly speaking it does do the job, but it's ridiculously overcomplicated and the market is littered with terrible implementations because of that complexity. Worst of all it was never truly necessary because a simpler specification (where's the UEFI equivalent of JSON?!) would have sufficed for all use cases.
Another thing reminds me of XML too. There was a good market in being an expert in XML for a while. It was almost a club, in fact. The arcaneness plus the reliance the world had on it made for some excellent opportunities. Opportunities that, say, JSON never provided.
There appears to be a good market to being the go to guy for UEFI too.
Just sayin'
Of course it predates ACPI, which Intel wanted to port over to IA64, and so it doesn't cooperate with it too well. It also wasn't made by Intel - which is the classic NIH argument, and from hearsay within the firmware subculture, that's exactly what happened. So they built EFI, which later morphed into UEFI.
With its PE format, FAT filesystem, GUID, and COM-alike protocol abstraction (not to forget, the coding style), maybe they should have called it "Windows for Firmware".
Which systems have you seen that have Secure Boot enabled by default and don't provide any mechanism for key management? Many vendors won't provide a UI for adding additional keys but will let you remove all existing ones and then enrol your choice - that's pretty much how the spec envisages this working.
> Let's say hypothetically that instead of being buried three menus deep, it was a physical switch, with a clear explanation about what it actually does.
And let's say that, hypothetically, hardware vendors refused to add a physical switch that would cost a few cents extra per board and have an effect on their bottom line. What then? And how do I prevent someone with brief physical access from flicking that switch and replacing my bootloader?
> Let's say hypothetically that trying to install an "untrusted" OS gave you a clear error message.
Microsoft don't have enough leverage over the firmware vendors to be able to mandate choice of language, so what you'd end up with is a variety of vendors with their own idea of what a clear error message is.
> DOJ pretends not to notice that Microsoft's secure boot initiative (if not the spec) is anti-competitive.
The number of lawyers I've found who, after having had all aspects of this explained to them, thought that Microsoft's behaviour here was anti-competitive is zero. There was a much stronger argument before Microsoft mandated that vendors provide a mechanism for performing key management and agreed to sign third party bootloaders. Now? Not so much.
> There appears to be a good market to being the go to guy for UEFI too.
I'm doing pretty well out of it. But I did pretty well out of BIOS before that, and if the market decides that Coreboot with a non-Tiano payload is the way forward then I suspect I'll be fine there as well.
All I've come across so far. Dells, Toshibas, a Lenovo, etc. I literally haven't seen a UI for key management at all. Ever.
MAYBE that's because it's too well hidden or maybe those machines I've looked at simply didn't have it.
>And let's say that, hypothetically, hardware vendors refused to add a physical switch that would cost a few cents extra per board
I'd say that non-hypothetically speaking, they were trying to stay on Microsoft's good side and coming up with a lame fucking excuse to do so.
That is, unless they came up with an equally good UI that didn't require a button, which is possible.
Someone on this thread mentioned that chromebooks have a button. When pretty much the lowest-cost point in the market can do it....
>Microsoft don't have enough leverage over the firmware vendors
Yes they do. If they have enough to mandate that it's written they have enough to mandate that it's written coherently. They just have every incentive to ensure that it isn't, and with a nod and a wink they can get their way.
>The number of lawyers I've found who, after having had all aspects of this explained to them, thought that Microsoft's behaviour here was anti-competitive is zero.
I wonder how many of those lawyers have ever tried to install linux with secure boot turned on.
Maybe they all thought that if the spec was kosher that's all that matters.
>I'm doing pretty well out of it.
That certainly explains the apologetics.
Maybe you don't know what you're doing.
> I'd say that non-hypothetically speaking, they were trying to stay on Microsoft's good side and coming up with a lame fucking excuse to do so.
I'd say that you don't know what you're talking about.
> Someone on this thread mentioned that chromebooks have a button. When pretty much the lowest-cost point in the market can do it....
Except Google are able to precisely define what a Chromebook looks like - if you don't manufacture to Google's specifications, you don't get to ship ChromeOS. Which, if Google were to dominate the market, would probably be the point where you'd decry them as behaving in anticompetitive ways.
Microsoft have to perform an interesting balancing act. Vendors will adhere to the Windows hardware certification requirements because it saves them money per-unit. Microsoft can demand new firmware features because that's a one-off cost per new platform. Hardware features cost per unit, and if they push that too far it's cheaper for manufacturers to tell Microsoft to fuck off and market their hardware without the Windows sticker. That's simply not an option in the ChromeOS market. You can't compare them.
> Yes they do.
So cool you don't know what you're talking about.
> I wonder how many of those lawyers have ever tried to install linux with secure boot turned on.
Linux distributions having fucking dreadful installers really isn't what determines whether something is an antitrust violation or not. Linux distributions not being able to get their shit together sufficiently to get things signed isn't either. Canonical, Red Hat and Suse (and a whole host of smaller distributions and specialised products) have managed to deal with this.
> That certainly explains the apologetics.
I've also done pretty well out of OpenStack, but I'd be the first to admit that it's dreadful.
I triple checked on two computers to be sure. Nada. Maybe go fuck yourself.
>I'd say that you don't know what you're talking about.
And I'd say you should stick to low level coding and not comment on the economics of competition and the contents of the US vs. Microsoft dockets... unless you are an antitrust lawyer, an economist AND a kernel hacker?
Thought not.
>Except Google are able to precisely define what a Chromebook looks like
So a single switch is monstrously expensive unless Google mandates it, in which case it's not a problem.
>So cool you don't know what you're talking about.
Jesus Christ you are so fucking lame.
>Linux distributions having fucking dreadful installers really isn't what determines whether something is an antitrust violation or not.
It's the FIRMWARE's job to tell you that it's "saving you from yourself", not the installers.
>Linux distributions not being able to get their shit together sufficiently to get things signed isn't either. Canonical, Red Hat and Suse (and a whole host of smaller distributions and specialised products) have managed to deal with this.
Funny. I tried installing (the latest release of) Ubuntu the other day and got nothing but a cryptic error message because secure boot was turned off.
For the Thinkpad I have here:
1) Enter firmware 2) Go to security 3) Select "Reset to Setup Mode" 4) Enrol keys using UEFI SetVariable() interface
What models are you talking about? Shipping with no mechanism to do this is in violation of the Windows hardware certification requirements, and vendors falsely claiming compliance are both falsely advertising and breaching their contracts with Microsoft, so it's a pretty big deal for them to do so.
> And I'd say you should stick to low level coding and not comment on the economics of competition and the contents of the US vs. Microsoft dockets... unless you are an antitrust lawyer, an economist AND a kernel hacker?
You are an antitrust lawyer and an economist?
> So a single switch is monstrously expensive unless Google mandates it, in which case it's not a problem.
In the Windows world, if Microsoft's demands become too extreme you can ignore Microsoft, undercut your competitors and ship Windows anyway. In the ChromeOS world, you can't.
> Funny. I tried installing (the latest release of) Ubuntu the other day and got nothing but a cryptic error message because secure boot was turned off.
If Secure Boot is turned off then your inability to boot Ubuntu has nothing to do with Secure Boot.
It's a shame OEMs don't use the open source Coreboot instead, which could be audited as well for security vulnerabilities, and at least on Chromebooks, Google also provides a physical switch.
The problem is that this process of whom to choose is completely opaque and usually based upon who has the most market power, definitely not who is the most trustworthy.
Hence tons of OEMs ship with Microsoft's key being the only trusted one.
Imagine if the only CA trusted in 95% of browsers was Microsoft's CA. We'd be seeing blog posts like this telling us that since we didn't read the SSL spec, and because it's open, we're all just a bunch of know-nothing whingers :)
Let's face it, most motherboards will run Windows, so it makes sense to ship Microsoft's keys (also they have to do that to get certified by Windows). Do you really expect OEMs to go hunting down keys from Red Hat, SuSE and Canonical? What about all the other little distros? I would expect that companies like Microsoft know how to handle key material properly (plus they have a vested interest in doing it correctly), but how much do you trust all the little distros? Once a key is trusted, it's trusted, so if you want Secure Boot to do-what-it-says-on-the-tin, you need to have confidence that the pre-installed keys are all kosher.
And the CA model will definitely not work - we have seen what happens in the browser world. One bad CA, one bad signed certificate and the game is lost. And since it's running in firmware, there's no easy way to revoke or blacklist certificates.
I run Linux exclusively on my PC (and have for 15 years) so I'm sympathetic with everyone's concerns with Secure Boot, but I also completely understand why only Microsoft's key is pre-installed on most systems, and I believe that's probably the correct solution. The fact that the UIs for installing new keys or disabling Secure Boot suck is a good point. Complaining that Microsoft's key being the only pre-installed key isn't.
4/5 biggest linux distros. BSD, maybe? Does that seem unreasonable? Would you complain if these keys were added?
>Let's face it, most motherboards will run Windows, so it makes sense to ship Microsoft's keys (also they have to do that to get certified by Windows). Do you really expect OEMs to go hunting down keys from Red Hat, SuSE and Canonical?
Gosh, no. That sounds super hard. Three whole public keys?
>What about all the other little distros?
Give the end user an easy way to add their keys and I'm happy.
>And the CA model will definitely not work
You seem to be missing the point. This IS the CA model.
Basically, yeah - it'd remove much of the legal incentive for Microsoft to sign other operating systems, and it'd fuck over the smaller distributions as a result.
I don't think anybody's happy with Microsoft being the effective industry CA here (Microsoft certainly aren't), but nobody else has shown any real interest in taking responsibility for doing it.
That's the impression I got when I first heard of UEFI and decided to look at the specs/features, and it's the impression I had again when I read this article: A horrible mess of complexity that introduces even more bugs while trying to solve a very simple problem, and somehow the author is trying to justify it by enumerating some theoretical "problems" of legacy BIOS that I don't think really existed. Here are some rebuttals to pieces from the article...
which is that there’s no reliable convention for where the first partition should begin, so it’s difficult to be sure there’ll be enough space.
The MBR layout has been pretty much standardised, even if not officially - just look at the partition entries in it.
The only way to do this, in the BIOS/MBR world, is for the bootloaders to handle it; but there’s no widely accepted convention for the right way to do this.
It doesn't matter, you just have to figure out what each OS's bootloaders do, and whether you can chain them (most of them do.)
another advantage of UEFI booting: it provides a standard way for booting from, for instance, a remote server.
PXE does this and it's been in traditional BIOSes for a long time...
There’s no mechanism for levels above the firmware to configure the firmware’s boot behaviour.
I'd consider that a good thing.
Hopefully it’s clear why this is a better design: instead of having to write bootloader code to the ‘magic’ space at the start of an MBR disk, operating systems and so on can just create, format and mount partitions in a widely understood format and put bootloader code and anything else that they might want the firmware to read there.
The firmware shouldn't need to incorporate a filesystem driver, because that is a higher-level functionality. Its job should just be to initialise the hardware, boot from a disk/network/etc., and get out of the way. In this regard, the traditional and very elegantly simple "read the first 512 bytes from the selected boot device (it need not be a disk, PXE does this) into memory at 7c00h and jump to it" is probably the best way to do it.
“Any firmware is crap code”. Usually pretty accurate.
Ironic, since with UEFI there's plenty more code to go wrong than there is with traditional BIOS. I agree with Linus Torvalds' opinion of it:
The UEFI world seems to be very clubby. I suspect its arcaneness and the lucrative nature of working in it contributes to this.
I've seen this patronizing straw man "you don't know the spec like I do" from a few other UEFI blog posts, too.
Referring to UEFI as the "BIOS" is incorrect but is used commonly in the "IT World" (along with loads of other incorrect stuff...). The BIOS is understood as the thing where you configure basic hardware settings. I don't know if we're going to win that battle.
The Windows equivalent of efibootmgr is bcdedit. It isn't well documented.
In general, I think if you have the option to use UEFI and GPT they are better than the alternatives. I disable Secure Boot when installing Linux but I haven't installed it alongside Win 8 yet.
The "you have to be in UEFI mode to install an UEFI-bootable OS" is an important point.