本文转载于： https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
本文翻译于：http://www.tuicool.com/articles/NNf26jB
PDF整理版下载：http://yun.baidu.com/share/link?shareid=3376946296&uk=2643853
It’s AdamW Essay Time again! If you’relooking for something short and snappy, look elsewhere.
Kamil Paral kindly informs me I’m a chronicsufferer of Graphomania. Always nice to know what’s wrong with you.
IMPORTANT NOTE TO INDUSTRY FOLKS: This blogpost is aimed at regular everyday folks; it’s intended to dispel a few commonmyths and help regular people understand UEFI a bit better. It is not alow-level fully detailed and 100% technically accurate explanation, and I’m nota professional firmware engineer or anything like that. If you’re actuallybuilding an operating system or hardware or something, please don’t rely on mysimplified explanations or ask me for help; I’m just an idiot on the internet.If you’re doing that kind of thing and you have money, join the UEFI Forum orask your suppliers or check your reference implementation or whatever. If youdon’t have money, try asking your peers with more experience, nicely. ENDIMPORTANT NOTE
You’ve probably read a lot of stuff on theinternet about UEFI. Here is something important you should understand: 95% ofit was probably garbage. If you think you know about UEFI, and you derived yourknowledge anywhere other than the UEFI specifications, mjg59’s blog or one of afew other vaguely reliable locations/people – Rod Smith, or Peter Jones, orChris Murphy, or the documentation of the relatively few OSes whose developersactually know what the hell they’re doing with UEFI – what you think you knowis 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 offirmware that matters most to most people, and the bit news sites are alwaysbanging on about and wildly misunderstanding.
Terminology
First, let’s get some terminology out ofthe way. Both BIOS and UEFI are types of firmware for computers. BIOS-stylefirmware is (mostly) only ever found on IBM PC compatible computers. UEFI ismeant to be more generic, and can be found on systems which are not in the ‘IBMPC 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 forall PC firmware, it is a particular type of PC firmware. Your computer has afirmware. If it’s an IBM PC compatible computer, it’s almost certainly either aBIOS 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 singleeffectively optional element of the UEFI specification, which was added in version2.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 tounderstand what Secure Boot is, and what UEFI is, and which of the two you areactually talking about at any given time. We’ll talk about UEFI first, and thenwe’ll talk about Secure Boot as an ‘extension’ to UEFI, because that’sbasically what it is.
Bonus Historical Note: UEFI was notinvented by, is not controlled by, and has never been controlled by Microsoft.Its predecessor and basis, EFI, was developed and published by Intel. UEFI ismanaged by the UEFI Forum. Microsoft is a member of the UEFI forum. So is RedHat, 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 consensusspecification, with all the messiness that entails, some of which we’ll talkabout specifically later. It is no one company’s Evil Vehicle Of Evilness.
References
If you really want to understand UEFI, it’sa really good idea to go and read the UEFI specification. You can do this. It’svery easy. You don’t have to pay anyone any money. I am not going to tell youthat reading it will be the most fun you’ve ever had, because it won’t. But itwon’t be a waste of your time. You can find it right here on the official UEFIsite. You have to check a couple of boxes, but you are not signing your soulaway to Satan, or anything. It’s fine. As I write this, the current version ofthe spec is 2.4 Errata A, and that’s the version this post is written withregard to.
There is no BIOS specification. BIOS is ade 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 considertwo worlds. One is the world of IBM PC compatible computers – hereafterreferred to just as PCs – before UEFI and GPT (we’ll come to GPT) existed. Thisis the world a lot of you are probably familiar with and may understand quitewell. Let’s talk about how booting works on PCs with BIOS firmware.
BIOS booting
It works, in fact, in a very, very simpleway. On your bog-standard old-skool BIOS PC, you have one or more disks whichhave an MBR. The MBR is another de facto standard; basically, the very start ofthe disk describes the partitions on the disk in a particular format, andcontains a ‘boot loader’, a very small piece of code that a BIOS firmware knowshow to execute, whose job it is to boot the operating system(s). (Modernbootloaders frequently are much bigger than can be contained in the MBR spaceand have to use a multi-stage design where the bit in the MBR just knows how toload the next stage from somewhere else, but that’s not important to us rightnow).
All a BIOS firmware knows, in the contextof booting the system, is what disks the system contains. You, the owner ofthis BIOS-based computer, can tell the BIOS firmware which disk you want it toboot the system from. The firmware has no knowledge of anything beyond that. Itexecutes the bootloader it finds in the MBR of the specified disk, and that’sit. The firmware is no longer involved in booting.
In the BIOS world, absolutely all forms ofmulti-booting are handled above the firmware layer. The firmware layer doesn’treally know what a bootloader is, or what an operating system is. Hell, itdoesn’t know what a partition is. All it can do is run the boot loader from adisk’s MBR. You also cannot configure the boot process from outside of thefirmware.
UEFI booting: background
OK, so we have our background, the BIOSworld. Now let’s look at how booting works on a UEFI system. Even if you don’tgrasp the details of this post, grasp this: it is completely different.Completely and utterly different from how BIOS booting works. You cannot applyany of your understanding of BIOS booting to native UEFI booting. You cannotmake a little tweak to a system designed for the world of BIOS booting andapply it to native UEFI booting. You need to understand that it is a completelydifferent world.
Here’s another important thing tounderstand: many UEFI firmwares implement some kind of BIOS compatibility mode,sometimes referred to as a CSM. Many UEFI firmwares can boot a system just likea BIOS firmware would – they can look for an MBR on a disk, and execute theboot loader from that MBR, and leave everything subsequently up to thatbootloader. 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 understandwhat people really mean when they say it. They are talking about using a UEFIfirmware’s ability to boot the system ‘BIOS-style’ rather than native UEFIstyle.
What I’m going to describe is native UEFIbooting. If you have a UEFI-based system whose firmware has the BIOScompatibility feature, and you decide to use it, and you apply this decisionconsistently, then as far as booting is concerned, you can pretend your systemis 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 itconsistently. I really can’t recommend strongly enough that you do not attemptto mix UEFI-native and BIOS-compatible booting of permanently-installedoperating systems on the same computer, and especially not on the same disk. Itis a terrible terrible idea and will cause you heartache and pain. If youdecide to do it, don’t come crying to me.
For the sake of sanity, I am going toassume the use of disks with a GPT partition table, and EFI FAT32 EFI systempartitions. Depending on how deep you’re going to dive into this stuff you mayfind out that it’s not strictly speaking the case that you can always assumeyou’ll be dealing with GPT disks and EFI FAT32 ESPs when dealing with UEFInative boot, but the UEFI specification is quite strongly tied to GPT disks andEFI FAT32 ESPs, and this is what you’ll be dealing with in 99% of cases. Unlessyou’re dealing with Macs, and quite frankly, screw Macs.
Edit note: the following sections (up toImplications and Complications) were heavily revised on 2014-01-26, a few hoursafter the initial version of this post went up, based on feedback from PeterJones. Consider this to be v2.0 of the post. An earlier version was written ina somewhat less accurate and more confusing way.
UEFI native booting: how it actually works– background
OK, with that out of the way, let’s get tothe meat. This is how native UEFI booting actually works. It’s probably helpfulto go into this with a bit of high-level background.
UEFI provides much more infrastructure atthe firmware level for handling system boot. It’s nowhere near as simple asBIOS. Unlike BIOS, UEFI certainly does understand, to varying degrees, theconcepts of ‘disk partitions’ and ‘bootloaders’ and ‘operating systems’.
You can sort of look at the BIOS bootprocess, and look at the UEFI process, and see how the UEFI process extendsvarious bits to address specific problems.
The BIOS/MBR approach to finding thebootloader is pretty janky, when you think about it. It’s very ‘special sauce’:this particular tiny space at the front of the disk contains magic code thatonly really makes much sense to the system firmware and special utilities forwriting it. There are several problems with this approach.
It’s inconvenient to deal with – you needspecial utilities to write the MBR, and just about the only way to find outwhat’s in one is to dd the contents out and examine them.
As noted above, the MBR itself is not bigenough for many modern bootloaders. What they do is install a small part ofthemselves to the MBR proper, and the rest to the empty space on the diskbetween where the conventional MBR ends and the first partition begins. There’sa rather big problem with this (well, the whole design is a big problem, butnever mind), which is that there’s no reliable convention for where the firstpartition should begin, so it’s difficult to be sure there’ll be enough space.One thing you usually can rely on is that there won’t be enough space for somebootloader configurations.
The design doesn’t provide any standardizedlayer or mechanism for selecting boot targets other than disks…but people wantto select boot targets other than disks. i.e. they want to have multiplebootable ‘things’ – usually operating systems – per disk. The only way to dothis, in the BIOS/MBR world, is for the bootloaders to handle it; but there’sno widely accepted convention for the right way to do this. There are many manydifferent approaches, none of which is particularly interoperable with any ofthe others, none of which is a widely accepted standard or convention, and it’svery difficult to write tooling at the OS / OS installation layer that handlesmultiboot cleanly. It’s just a very messy design.
The design doesn’t provide a standard wayof booting from anything except disks. We’re not going to really talk aboutthat in this article, but just be aware it’s another advantage of UEFI booting:it provides a standard way for booting from, for instance, a remote server.
There’s no mechanism for levels above thefirmware to configure the firmware’s boot behaviour.
So you can imagine the UEFI Elves sittingaround and considering this problem, and coming up with a solution. Instead ofthe firmware only knowing about disks and one ‘magic’ location per disk wherebootloader code might reside, UEFI has much more infrastructure at the firmwarelayer for handling boot loading. Let’s look at all the things it defines thatare relevant here.
EFI executables
The UEFI spec defines an executable formatand requires all UEFI firmwares be capable of executing code in this format.When you write a bootloader for native UEFI, you write in this format. This ispretty simple and straightforward, and doesn’t need any further explanation:it’s just a Good Thing that we now have a firmware specification which actuallydefines a common format for code the firmware can execute.
The GPT (GUID partition table) format
The GUID Partition Table format is verymuch tied in with the UEFI specification, and again, this isn’t somethingparticularly complex or in need of much explanation, it’s just a good bit ofgroundwork the spec provides. GPT is just a standard for doing partition tables– the information at the start of a disk that defines what partitions that diskcontains. It’s a better standard for doing this than MBR/’MS-DOS’ partitiontables were in many ways, and the UEFI spec requires that UEFI-compliantfirmwares be capable of interpreting GPT (it also requires them to be capable ofinterpreting MBR, for backwards compatibility). All of this is usefulgroundwork: what’s going on here is the spec is establishing certaincapabilities that everything above the firmware layer can rely on the firmwareto have.
EFI system partitions
I actually really wrapped my head aroundthe EFI system partition concept while revising this post, and it was a great‘aha!’ moment. Really, the concept of ‘EFI system partitions’ is just an answerto the problem of the ‘special sauce’ MBR space. The concept of some undefinedamount of empty space at the start of a disk being ‘where bootloader codelives’ is a pretty crappy design, as we saw above. EFI system partitions arejust UEFI’s solution to that.1
The solution is this: we require thefirmware layer to be capable of reading some specific types of filesystem. TheUEFI spec requires that compliant firmwares be capable of reading the FAT12,FAT16 and FAT32 variants of the FAT format, in essence. In fact what it does iscodify a particular interpretation of those formats as they existed at thepoint UEFI was accepted, and say that UEFI compliant firmwares must be capableof reading those formats. As the spec puts it:
“The file system supported by the Extensible Firmware Interface isbased on the FAT file system. EFI defines a specific version of FAT that isexplicitly documented and testable. Conformance to the EFI specification andits associate reference documents is the only definition of FAT that needs tobe implemented to support EFI. To differentiate the EFI file system from pureFAT, a new partition file system type has been defined.”
An ‘EFI system partition’ is really justany partition formatted with one of the UEFI spec-defined variants of FAT andgiven a specific GPT partition type to help the firmware find it. And thepurpose of this is just as described above: allow everyone to rely on the factthat the firmware layer will definitely be able to read data from a pretty‘normal’ disk partition. Hopefully it’s clear why this is a better design:instead of having to write bootloader code to the ‘magic’ space at the start ofan MBR disk, operating systems and so on can just create, format and mountpartitions in a widely understood format and put bootloader code and anythingelse that they might want the firmware to read there.
The whole ESP thing seemed a bit bizarreand confusing to me at first, so I hope this section explains why it’s actuallya very sensible idea and a good design – the bizarre and confusing thing isreally the BIOS/MBR design, where the only way for you to write something fromthe OS layer that you knew the firmware layer could consume was to write itinto some (but you didn’t know how much) Magic Space at the start of a disk, aconvention which isn’t actually codified anywhere. That really isn’t a verysensible or understandable design, if you step back and take a look at it.
As we’ll note later, the UEFI spec tends totake a ‘you must at least do these things’ approach – it rarely prohibitsfirmwares from doing anything else. It’s not against the spec to write afirmware that can execute code in other formats, read other types of partitiontable, and read partitions formatted with filesystems other than the UEFIvariants of FAT. But a UEFI compliant firmware must at least do all these things,so if you are writing an OS or something else that you want to run on any UEFIcompliant firmware, this is why the EFI system partition concept is soimportant: it gives you (at least in theory) 100% confidence that you can putan EFI executable on a partition formatted with the UEFI FAT implementation andthe correct GPT partition type, and the system firmware will be able to readit. This is the thing you can take to the bank, like ‘the firmware will be ableto execute some bootloader code I put in the MBR space’ was in the BIOS world.
So now we have three important bits ofgroundwork the UEFI spec provides: thanks to these requirements, any otherlayer can confidently rely on the fact that the firmware:
Can read a partition table
Can access files in some specificfilesystems
Can execute code in a particular format
This is much more than you can rely on aBIOS firmware being capable of. However, in order to complete the vision of afirmware layer that can handle booting multiple targets – not just disks – weneed one more bit of groundwork: there needs to be a mechanism by which thefirmware finds the various possible boot targets, and a way to configure it.
The UEFI boot manager
The UEFI spec defines something called theUEFI boot manager. (Linux distributions contain a tool called efibootmgr whichis used to manipulate the configuration of the UEFI boot manager). As a sampleof what you can expect to find if you do read the UEFI spec, it defines theUEFI boot manager thusly:
“The UEFI boot manager is a firmware policy engine that can beconfigured by modifying architecturally defined global NVRAM variables. Theboot manager will attempt to load UEFI drivers and UEFI applications (includingUEFI OS boot loaders) in an order defined by the global NVRAM variables.”
Well, that’s that cleared up, let’s moveon. No, not really. Let’s translate thatto Human. With only a reasonable degree of simplification, you can think of theUEFI boot manager as being a boot menu. With a BIOS firmware, your firmwarelevel ‘boot menu’ is, necessarily, the disks connected to the system at boottime – no more, no less. This is not true with a UEFI firmware.
The UEFI boot manager can be configured –simply put, you can add and remove entries from the ‘boot menu’. The firmwarecan also (it fact the spec requires it to, in various cases) effectively‘generate’ entries in this boot menu, according to the disks attached to thesystem and possibly some firmware configuration settings. It can also beexamined – you can look at what’s in it.
One rather great thing UEFI provides is amechanism for doing this from other layers: you can configure the system bootbehaviour from a booted operating system. You can do all this by using theefibootmgr tool, once you have Linux booted via UEFI somehow. There are Windowstools for it too, but I’m not terribly familiar with them. Let’s have a look atsome typical efibootmgr output, which I stole and slightly tweaked from theFedora forums:
[root@system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(EFIfedoragrubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(EFIopensusegrubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
[root@system directory]#
This is a nice clean example I stole andslightly tweaked from the Fedora forums. We can see a few things going on here.
The first line tells you which of the ‘bootmenu’ entries you are currently booted from. The second is pretty obvious (ifthe 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). TheBootOrder is the order in which the entries in the list will be tried. The restof the output shows the actual boot entries. We’ll describe what they actuallydo later.
If you boot a UEFI firmware entirelynormally, without doing any of the tweaks we’ll discuss later, what it ought todo is try to boot from each of the ‘entries’ in the ‘boot menu’, in the orderlisted in BootOrder. So on this system it would try to boot the entry called‘opensuse’, then if that failed, the one called ‘Fedora’, then ‘CD/DVD Drive’,and then the second ‘Hard Drive’.
UEFI native booting: how it actually works– boot manager entries
What does these entries actually mean,though? There’s actually a huge range of possibilities that makes up rather alarge part of the complexity of the UEFI spec all by itself. If you’re readingthe spec, pour yourself an extremely large shot of gin and turn to theEFI_DEVICE_PATH_PROTOCOL section, but note that this is a generic protocolthat’s used for other things than booting – it’s UEFI’s Official Way OfIdentifying Devices For All Purposes, used for boot manager entries but alsofor all sorts of other purposes. Not every possible EFI device path makes senseas a UEFI boot manager entry, for obvious reasons (you’re probably not going toget too far trying to boot from your video adapter). But you can certainly havean entry that points to, say, a PXE server, not a disk partition. The spec haslots of bits defining valid non-disk boot targets that can be added to the UEFIboot manager configuration.
For our purposes, though, lets justconsider fairly normal disks connected to the system. In this case we canconsider three types of entry you’re likely to come across.
BIOS compatibility boot entries
Boot0000 and Boot0004 in this example areactually BIOS compatibility mode entries, not UEFI native entries. They havenot been added to the UEFI boot manager configuration by any external agency,but generated by the firmware itself – this is a common way for a UEFI firmwareto implement BIOS compatibility booting, by generating UEFI boot managerentries that trigger a BIOS-compatible boot of a given device. How they presentthis to the user is a different question, as we’ll see later. Whether you seeany of these entries or not will depend on your particular firmware, and itsconfiguration. Each of these entries just gives a name – ‘CD/DVD Drive’, ‘HardDrive’ – and says “if this entry is selected, boot this disk (where ‘this disk’is 3,0,00 for Boot0000 and 2,0,00 for Boot0004) in BIOS compatibility mode”.
‘Fallback path’ UEFI native boot entries
Boot0001 is an entry (fictional, andsomewhat unlikely, but it’s for illustrative purposes) that tells the firmwareto try and boot from a particular disk, and in UEFI mode not BIOS compatibilitymode, but doesn’t tell it anything more. It doesn’t specify a particular boottarget on the disk – it just says to boot the disk.
The UEFI spec defines a sort of ‘fallback’path for booting this kind of boot manager entry, which works in principlesomewhat like BIOS drive booting: it looks in a standard location for some bootloader code. The details are different, though.
What the firmware will actually do whentrying to boot in this way is reasonably simple. The firmware will look througheach EFI system partition on the disk in the order they exist on the disk.Within the ESP, it will look for a file with a specific name and location. Onan x86-64 PC, it will look for the file EFIBOOTBOOTx64.EFI. What it actuallylooks for is EFIBOOTBOOT{machine type short-name}.EFI – ‘x64’ is the“machine type short-name” for x86-64 PCs. The other possibilities areBOOTIA32.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 thenexecute the first qualifying file it finds (obviously, the file needs to be inthe executable format defined in the UEFI specification).
This mechanism is not designed for bootingpermanently-installed OSes. It’s more designed for booting hotpluggable,device-agnostic media, like live images and OS install media. And this isindeed what it’s usually used for. If you look at a UEFI-capable live orinstall medium for a Linux distribution or other OS, you’ll find it has a GPTpartition table and contains a FAT-formatted partition at or near the start ofthe device, with the GPT partition type that identifies it as an EFI systempartition. Within that partition there will be a EFIBOOT directory with atleast one of the specially-named files above. When you boot a Fedora live orinstall medium in UEFI-native mode, this is the mechanism that is used. TheBOOTx64.EFI (or whatever) file handles the rest of the boot process from there,booting the actual operating system contained on the medium.
Full UEFI native boot entries
Boot0002 and Boot0003 are ‘typical’ entriesfor operating systems permanently installed to permanent storage devices. Theseentries show us the full power of the UEFI boot mechanism, by not just saying“boot from this disk”, but “boot this specific bootloader in this specificlocation on this specific disk”, using all the ‘groundwork’ we talked aboutabove.
Boot0002 is a boot entry produced by aUEFI-native Fedora installation. Boot0003 is a boot entry produced by aUEFI-native OpenSUSE installation. As you may be able to tell, all they’resaying is “load this file from this partition”. The partition is theHD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d) bit: that’s referring to aspecific partition (using the EFI_DEVICE_PATH_PROTOCOL, which I’m really notgoing to attempt to explain in any detail – you don’t necessarily need to knowit, if you interact with the boot manager via the firmware interface andefibootmgr). The file is the File(EFIopensusegrubx64.efi) bit: that justmeans “load the file in this location on the partition we just described”. Thepartition in question will almost always be one that qualifies as an EFI systempartition, because of the considerations above: that’s the type of partition wecan trust the firmware to be able to access.
This is the mechanism the UEFI specprovides for operating systems to make themselves available for booting: theoperating system is intended to install a bootloader which loads the OS kerneland so on to an EFI system partition, and add an entry to the UEFI boot managerconfiguration with a name – obviously, this will usually be derived from theoperating system’s name – and the location of the bootloader (in EFI executableformat) that is intended for loading that operating system.
Linux distributions use the efibootmgr toolto deal with the UEFI boot manager. What a Linux distribution actually does, sofar as bootloading is concerned, when you do a UEFI native install is really prettysimple: it creates an EFI system partition if one does not already exist,installs an EFI boot loader with an appropriate configuration – oftengrub2-efi, but there are others – into a correct path in the EFI systempartition, and calls efibootmgr to add an appropriately-named UEFI boot managerentry pointing to its boot loader. Most distros will use an existing EFI systempartition if there is one, though it’s perfectly valid to create a new one anduse that instead: as we’ve noted, UEFI is a permissive spec, and if you followthe design logically, there’s really no problem with having just as many EFIsystem partitions as you want.
Configuring the boot process (the firmwareUI)
The above describes the basic mechanism theUEFI spec defines that manages the UEFI boot process. It’s important to realizethat your firmware user interface may well not represent this mechanism veryclearly. Unfortunately, the spec intentionally refrains from defining how theboot process should be represented to the user or how the user should beallowed to configure it, and what that means – since we’re dealing withfirmware engineers – is that every firmware does it differently, and some do itinsanely.
Many firmwares do have fairly reasonableinterfaces for boot configuration. A good firmware design will at least showyou the boot order, with a reasonable representation of the entries on it, andlet you add or remove entries, change the order, or override the order for aspecific boot (by changing it just for that boot, or directly instructing thefirmware to boot a particular menu entry, or even giving you the option tosimply say “boot this disk”, either in BIOS compatibility mode or UEFI‘fallback’ mode – my firmware does this). Such an interface will often show‘full’ UEFI native boot entries (like the Fedora and openSUSE examples we sawearlier) only by their name; you have to examine the efibootmgr -v output toknow precisely what these entries will actually try and do when invoked.
Some firmwares try to abstract and simplifythe configuration, and may do a good or a bad job of it. For instance, if youhave an option to ‘enable or disable’ BIOS compatibility mode, what it’llreally likely do add is configure whether the firmware adds BIOS compatibilityentries for attached drives to the UEFI boot manager configuration or not. Ifyou have an option to ‘enable or disable’ UEFI native booting, what likelyreally happens when you ‘disable’ it is that the firmware changes the UEFI bootmanager configuration to leave all UEFI-native entries out of the BootOrder.
The key point to remember is that anyconfiguration option inside your firmware interface which is to do with bootingis really, behind the scenes, configuring the behaviour of the UEFI bootmanager. If you understand all the stuff we’ve discussed above, you may wellfind it easier to figure out what’s really happening when you twiddle the knobsyour firmware interface exposes.
In the BIOS world, you’ll remember, youdon’t always find that systems are configured to try and boot from removabledrives – CD, USB – before booting from permanent drives. Some are, and somearen’t. Some will try CD before the hard disks, but not USB. People have gotfairly used to having to check the BIOS configuration to ensure the boot orderis ‘correct’ when trying to install a new operating system.
This applies to the UEFI world too, butbecause of the added flexibility/complexity of the UEFI boot manager mechanism,it can look unfamiliar and scary.
If you want to ensure that your systemtries to boot from removable devices using the ‘fallback’ mechanism before ittries to boot ‘permanent’ boot entries – as you will want to do if you want to,say, install Fedora – you need this to be the default for your firmware, or youneed to be able to tell the firmware this. Depending on your firmware’sinterface, you may find there is a ‘menu entry’ for each attached removabledevice and you just have to adjust the boot order to put it at the top of thelist, or you may find that there is the mechanism to directly request ‘UEFIfallback boot of this particular disk’, or you may find that the firmware triesto abstract the configuration somehow. We just don’t know, and that makeswriting instructions for this quite hard. But now you broadly understand howthings work behind the scenes, you may find it easier to understand yourfirmware user interface’s representation of that.
Configuring the boot process (from an operatingsystem)
As we’ve noted above, unlike in the BIOSworld, you can actually configure the UEFI boot process from the operatingsystem level. If you have an insane firmware, you may have to do this in orderto achieve what you want.
You can use the efibootmgr tool mentionedearlier to add, delete and modify entries in the UEFI boot managerconfiguration, and actually do quite a lot of other stuff with it too. You canchange the boot order. You can tell it to boot some particular entry in thelist on the next boot, instead of using the BootOrder list (if you or someother tool has configured this to happen, your efibootmgr -v output willinclude a BootNext item stating which menu entry will be loaded on the nextboot). There are tools for Windows that can do this stuff from Windows, too. Soif you’re really struggling to manage to do whatever it is you want to do withUEFI boot configuration from your firmware interface, but you can boot a UEFInative operating system of some kind, you may want to consider doing your bootconfiguration from that operating system rather than from the firmware UI.
So to recap:
Your UEFI firmware contains something verylike what you think of as a boot menu.
You can query its configuration withefibootmgr -v, from any UEFI-native boot of a Linux OS, and also change itsconfiguration with efibootmgr (see the man page for details).
This ‘boot menu’ can contain entries thatsay ‘boot this disk in BIOS compatibility mode’, ‘boot this disk in UEFI nativemode via the fallback path’ (which will use the ‘look for BOOT(something).EFI’method described above), or ‘boot the specific EFI format executable at thisspecific location (almost always on an EFI system partition)’.
The nice, clean design that the UEFI specis trying to imply is that all operating systems should install a bootloader oftheir own to an EFI system partition, add entries to this ‘boot menu’ thatpoint to themselves, and butt out from trying to take control of bootinganything else.
Your firmware UI has free rein to representthis mechanism to you in whatever way it wants, and it may do this well, or itmay do this poorly.
Installing operating systems to UEFI-basedcomputers
Let’s have a quick look at some specificconsequences of the above that relate to installing operating systems on UEFIcomputers.
UEFI native and BIOS compatibility booting
Here’s a very very simple one which peoplesometimes miss:
If you boot the installation medium in‘UEFI native’ mode, it will do a UEFI native install of the operating system:it will try to write an EFI-format bootloader to an EFI system partition, andattempt to add an entry to the UEFI boot manager ‘boot menu’ which loads thatbootloader.
If you boot the installation medium in‘BIOS compatibility’ mode, it will do a BIOS compatible install of theoperating system: it will try to write an MBR-type bootloader to the magic MBRspace on a disk.
This applies (with one minor caveat I’mgoing to paper over for now) to all OSes of which I’m aware. So you probablywant to make sure you understand how, in your firmware, you can choose to boota removable device in UEFI native mode and how you can choose to boot it inBIOS compatibility mode, and make sure you pick whichever one you actually wantto use for your installation.
You really cannot do a completelysuccessful UEFI-native installation of an OS if you boot its installationmedium in BIOS compatibility mode, because the installer will not be able toconfigure the UEFI boot manager (this is only possible when bootedUEFI-native).
It is theoretically possible for an OSinstaller to install the OS in the BIOS style – that is, write a bootloader toa disk’s MBR – after being booted in UEFI native mode, but most of them won’tdo this, and that’s probably sensible.
Finding out which mode you’re booted in
It is possible that you might find yourselfwith your operating system installer booted, and not sure whether it’s actuallybooted in UEFI native mode or BIOS compatibility mode. Don’t panic! It’s prettyeasy to find out which, in a few different ways. One of the easiest is just totry and talk to the UEFI boot manager. If what you have booted is a Linuxinstaller or environment, and you can get to a shell (ctrl-alt-f2 in the Fedorainstaller, for instance), run efibootmgr -v. If you’re booted in UEFI nativemode, you’ll get your UEFI boot manager configuration, as shown above. Ifyou’re booted in BIOS compatibility mode, you’ll get something like this:
Fatal: Couldn’t open either sysfs or procfsdirectories for accessing EFI variables.
Try ‘modprobe efivars’ as root.
If you’ve booted some other operatingsystem, you can try running a utility native to that OS which tries to talk tothe UEFI boot manager, and see if you get sensible output or a similar kind oferror. Or you can examine the system logs and search for ‘efi’ and/or ‘uefi’,and you’ll probably find some kind of indication.
Enabling UEFI native boot
To be bootable in UEFI native mode, your OSinstallation medium must obviously actually comply with all this stuff we’vejust described: it’s got to have a GPT partition table, and an EFI systempartition with a bootloader in the correct ‘fallback’ path –EFIBOOTBOOTx64.EFI (or the other names for the other platforms). If you’rehaving trouble doing a UEFI native boot of your installation medium and can’tfigure out why, check that this is actually the case. Notably, when using thelivecd-iso-to-disk tool to write a Fedora image to a USB stick, you must passthe –efi parameter to configure the stick to be UEFI bootable.
Forcing BIOS compatibility boot
If your firmware seems to make it verydifficult to boot from a removable medium in BIOS compatibility mode, but youreally want to do that, there’s a handy trick you can use: just make the mediumnot UEFI native bootable at all. You can do this pretty easily by just wipingall the EFI system partitions. (Alternatively, if using livecd-iso-to-disk tocreate a USB stick from a Fedora image, you can just leave out the –efiparameter and it won’t be UEFI bootable). If at that point your firmwarerefuses to boot it in BIOS compatibility mode, commence swearing at yourfirmware vendor (if you didn’t already).
Disk formats (MBR vs. GPT)
Here’s another very importantconsideration:
If you want to do a ‘BIOS compatibility’type installation, you probably want to install to an MBR formatted disk.
If you want to do a UEFI nativeinstallation, you probably want to install to a GPT formatted disk.
Of course, to make life complicated, manyfirmwares can boot BIOS-style from a GPT formatted disk. UEFI firmwares are infact technically required to be able to boot UEFI-style from an MBR formatteddisk (though we are not particularly confident that they all really can). Butyou really should avoid this if at all possible. This consideration is quiteimportant, as it’s one that trips up quite a few people. For instance, it’s abad idea to boot an OS installer in UEFI native mode and then attempt toinstall to an MBR formatted disk without reformatting it. This is very likelyto fail. Most modern OS installers will automatically reformat the disk in thecorrect format if you allow them to completely wipe it, but if you try and tellthe installer ‘do a UEFI native installation to this MBR formatted disk anddon’t reformat it because it has data on it that I care about’, it’s very likelyto fail, even though this configuration is technically covered in the UEFIspecification. Specifically, Windows and Fedora at least explicitly disallowthis configuration.
Checking the disk format
You can use the parted utility to check theformat of a given disk:
[adamw@adam Downloads]$ sudo parted/dev/sda
GNU Parted 3.1
Using /dev/sda
Welcome to GNU Parted! Type ‘help’ to viewa list of commands.
(parted) p
Model: ATA C300-CTFDDAC128M (scsi)
Disk /dev/sda: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ext4 boot
2 525MB 128GB 128GB primary lvm
(parted)
See that Partition table: msdos? This is anMBR/MS-DOS formatted disk. If it was GPT-formatted, that would say gpt. You canreformat the disk with the other type of partition table by doing mklabel gptor mklabel msdos from within parted. This will destroy the contents of thedisk.
With most OS installers, if you pick a diskconfiguration that blows away the entire contents of the target disk, theinstaller will automatically reformat it using the most appropriate configurationfor the type of installation you’re doing, but if you want to use an existingdisk without reformatting it, you’re going to have to check how it’s formattedand take this into account.
Handling EFI system partition if doingmanual partitioning
I can only give authoritative advice forFedora here, but the gist may be useful for other distros / OSes.
If you allow Fedora to handle partitioningfor you when doing a UEFI native installation – and you use a GPT-formatteddisk, or allow it to reformat the disk (by deleting all existing partitions) –it will handle the EFI system partition stuff for you.
If you use custom partitioning, though, itwill expect you to provide an EFI system partition for the installer to use. Ifyou don’t do this, the installer will complain (with a somewhat confusing errormessage) and refuse to let you start the installation.
So if you’re doing a UEFI native installand using custom partitioning, you need to ensure that a partition of the ‘EFIsystem partition’ type is mounted at /boot/efi – this is where Fedora expectsto find the EFI system partition it’s using. If there is an existing EFI systempartition on the system, just set its mount point to /boot/efi. If there is notan EFI system partition yet, create a partition, set its type to EFI systempartition, make it at least 200MB big (500MB is good), and set its mount pointto /boot/efi.
A specific example
To boil down the above: if you bought aWindows 8 or later system, you almost certainly have a UEFI native install ofWindows to a GPT-formatted disk. This means that if you want to install anotherOS alongside that Windows install, you almost certainly want to do aUEFI-native installation of your other OS. If you don’t like all this UEFInonsense and want to go back to the good old world you’re familiar with, youwill, I’m afraid, have to blow away the UEFI-native Windows installation, andit would be a good idea to reformat the disk to MBR.
Implications and Complications
So, that’s how UEFI booting works, at leasta reasonable approximation. When I describe it like that, it almost all makessense, right?
However, all is not sweetness and light.There are problems. There always are.
Attentive readers may have noticed thatI’ve talked about the UEFI spec providing a mechanism. This is accurate, andimportant. As the UEFI spec is a ‘broad consensus’ sort of thing, one of itsmajor shortcomings (looked at from a particular perspective) is that it’snowhere near prescriptive enough.
If you read the UEFI spec critically, itsbasic approach is to define a set of functions that UEFI compliant firmwaresmust support. What it doesn’t do a lot of at all is strictly requiring thingsto be done in any particular way, or not done in any particular way.
So: the spec says that a system firmwaremust do all the stuff I’ve described above, in order to be considered aUEFI-compliant firmware. The spec, however, doesn’t talk about what operatingsystems ‘should’ or ‘must’ do at all, and it doesn’t say that firmwares mustnot support (or no-one may expect them to support, or whatever)…anything atall. If you’re making a UEFI firmware, in other words, you have to support GPTformatted disks, and FAT-formatted EFI system partitions, and you must readUEFI boot manager entries in the standard format, and you must do this and thatand the other – but you can also do any other crap you like.
It’s pretty easy to read certainimplications from the spec – it carefully sets up this nice mechanism forhandling OS (or other ‘bootable thing’) selection at the firmware level, forinstance, with the clear implication “hey, it’d be great if all OSes were writtento this mechanism”. But the UEFI spec doesn’t require that, and neither doesany other widely-respected specification.
So, what happens in the real world is thatwe wind up with really dumb crap. Apple, for instance, ships at least some Macswith their bootloaders in an HFS+ partition. The spec says a UEFI-compliantfirmware must support UEFI FAT partitions with the specific GPT partition typethat identifies them as an “EFI system partition”, but it doesn’t say thefirmware can’t also recognize some other filesystem type and load a bootloaderfrom that. (Whether you consider such a partition to be an “EFI systempartition” or not is an interesting philosophical conundrum, but let’s skateright over that for now).
The world would pretty clearly be a betterplace if everyone just damn well used the EFI system partition format the specgoes to such great pains to define, but Apple is Apple and we can’t have nicethings, so Apple went right ahead and wrote firmwares that also can read andload code from HFS+ partitions, and now everyone else has to deal with that ortell Macs to go and get boned. Apple also goes quite a long way beyond the specin its boot process design, and if you want your alternative OS to show up onits graphical boot menu with a nice icon and things, you have to do more thanwhat the UEFI spec would suggest.
There are various similar incrediblyannoying corner cases we’ve come across, but let’s not go into them all rightnow. This post is long enough.
Also, as we noted earlier, the spec makesno requirements as to how the mechanism should be represented to the user. Soif a couple of software companies write OSes to behave ‘nicely’ according tothe conventions the spec is clearly designed to back, and install EFI bootloaders and define EFI boot manager entries with nice clear names – like, ohsay, “Fedora” and “Windows” – they are implicitly relying on the firmware tothen give the user some kind of sane interface somewhere relativelydiscoverable that lets them choose to boot “Windows” or “Fedora”. The morefirmwares don’t do a good job of this, the less willing OS engineers will be torely on the ‘proper’ conventions, and the more likely they’ll be to startrebuilding ugly hacks above the firmware level.
To be fair, we could do somewhat more atthe OS level. We could present all those neat efibootmgr capabilities rathermore obviously – we can use that ‘don’t respect BootOrder on the next boot, butinstead boot this‘ capability, for instance, and have ‘Reboot to Windows’ as anoption. It’d be kinda nice if someone looked at exposing all this functionalitysomewhere more obvious than efibootmgr. Windows 8 systems do use this, to someextent – you can reboot your system to the firmware UI from the Windows 8settings menus, for instance. But still.
All this is really incredibly frustrating,because UEFI is so close to making things really a lot better. The BIOSapproach doesn’t provide any kind of convention or standard for multibooting atall – 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 wenever did, so it just became a multiple-decade epic fail, where each operatingsystem came up with its own approach and lots of people wrote their own bootloaderswhich tried to subsume all the operating systems and all the operating systemsand 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 carefullyestablishes, and mandated that firmwares provide a sensible user interface, thewin would have been epic. But it doesn’t, so it’s entirely possible that in aUEFI world things will be even worse than they were in the BIOS world. If manymore firmwares show up that don’t present a good UI for the UEFI boot managermechanism, what could happen is that OS vendors give up on the UEFI bootmanager mechanism (or decide to support it and alternatives, because choice!)and just reinvent the entire goddamn nightmare of BIOS multibooting on top ofUEFI – and we’ll all have to deal with all of that, plus the added complicationof the UEFI boot manager layer. You’ll have multiple bootloaders fighting toload multiple operating systems all on top of the whole UEFI boot managermechanism which is just throwing a whole bunch of other variables into theequation.
This is not a prospect filling the mind ofanyone who’s had to think about it with joy.
Still, it’s important to recognize that thesins of UEFI in this area are sins of omission – they are not sins ofcommission, 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 systemfirmware that doesn’t give you good access to the UEFI boot manager mechanismis not the UEFI forum, or Microsoft, and it certainly isn’t Fedora and evenmore certainly isn’t me ;). The entity you should be angry at is yoursystem/motherboard manufacturer and the goddamn incompetents they hired towrite the firmware, because the UEFI spec makes it really damn clear to anyonewith two brain cells to rub together that it would be a very good idea toprovide some kind of useful user interface to the UEFI boot manager, and anyfirmware which doesn’t do so is crap code by definition. Yes, the UEFI forumshould’ve realized that firmware engineers couldn’t code their way out of agoddamned paper bag and just ordered them to do so, but still, it’s ultimatelythe firmware engineers who should be lined up against the nearest wall.
Wait, we can simplify that. “Any firmwareis crap code”. Usually pretty accurate.
Secure Boot
So now we come, finally, to Secure Boot.
Secure Boot is not magic. It’s notcomplicated. OK, that’s a lie, it’s incredibly complicated, but the theoryisn’t very complicated. And no, Secure Boot itself is not evil. I am entirelycomfortable stating this as a fact, and you should be too, unless you think GPGis evil.
Secure Boot is defined in chapter 28 of theUEFI spec (2.4a, anyway). It’s actually a pretty clever mechanism. But what itdoes can be described very, very simply. It says that the firmware can containa set of signatures, and refuse to run any EFI executable which is not signedwith one of those signatures.
That’s it. Well, no, it really isn’t, butthat’s a reasonably acceptable simplification. Security is hard, so there areall kinds of wibbly bits to implementing a really secure bootchain using SecureBoot, and mjg59 can tell you all about them, or you can pour another large shotof gin and read the whole of chapter 28. But that’s the basic idea.
Using public key cryptography to verify theintegrity of something is hardly a radical or evil concept. Pretty much allLinux distributions depend on it – we sign our packages and have our packagemanagers go AWOOGA AWOOGA if you try to install a package which isn’t signedwith one of our keys. This isn’t us being evil, and I don’t think anyone’s everaccused an OS of being evil for using public key cryptographic signing toestablish trust in this way. Secure Boot is literally this exact same perfectlywidely accepted mechanism, applied to the boot chain. Yet because a bunch ofjournalists wildly grasped the wrong end of the stick, it’s widely consideredto 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 wherethey 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 theexecutive summary is that the spec is utterly and entirely about defining amechanism for doing cryptographic verification of a boot chain. It does notreally 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 takescare to allow for all the mechanisms involved to be configurable at multiplelevels. The word ‘Microsoft’ is not mentioned. It is not in any way, shape, orform a secret agenda for Microsoft’s domination of the world. If you doubtthis, at the very bloody least, go and read it. I’ve given you all thenecessary pointers. There is literally not a single legitimate reason I canthink of for anyone to be angry with the idea “hey, it’d be neat if there was amechanism for optional cryptographic verification of bootloader code in thisfirmware specification”. None. Not one.
Secure Boot in the real world
Most of the unhappiness about Secure Bootis not really about Secure Boot the mechanism – whether the people expressingthat unhappiness think it is or not – but about specific implementations ofSecure Boot in the real world.
The only one we really care about is SecureBoot as it’s implemented on PCs shipped with Microsoft Windows 8 or higherpre-installed.
Microsoft has these things called theWindows Hardware Certification Requirements. There they are. They are not TopSecret, 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 ofWindows from Microsoft to pre-install on your computers and have a nice“reassuring” ‘Microsoft Approved!’ sticker or whatever on the case, you have tocomply with these requirements. That’s all the force they have: they are notactually a part of the law of the United States or any other country, whateversome people seem to believe. Bill Gates cannot feed you to his sharks if yousell a PC that doesn’t comply with these requirements, so long as you don’twant a cheap copy of Windows to pre-install and a nice sticker. There isliterally no requirement for a PC sold outside the Microsoft licensing programto 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 implementSecure Boot, but can ship with it configured in literally absolutely any way itpleases (including turned off).
If you’re going to have very loud opinionsabout Secure Boot, you have zero excuse for not going and reading the Microsoftcertification requirements. Right now. I’ll wait. You can search for “SecureBoot” to get to the relevant bit. It starts at “System.Fundamentals.Firmware.UEFISecureBoot”.
You should read it. But here is a summaryof what it says.
Computers complying with the requirementsmust:
Ship with Secure Boot turned on (except forservers)
Have Microsoft’s key in the list of keysthey trust
Disable BIOS compatibility mode when SecureBoot is enabled (actually the UEFI spec requires this too, if I read itcorrectly)
Support signature blacklisting
x86 computers complying with therequirements must additionally:
Allow a physically present person to disableSecure Boot
Allow a physically present person to enableCustom Mode, and modify the list of keys the firmware trusts
ARM computers complying with therequirements must additionally:
NOT allow a physically present person todisable Secure Boot
NOT allow a physically present person toenable Custom Mode, and modify the list of keys the firmware trusts
Yes. You read that correctly. The Microsoftcertification requirements, for x86 machines, explicitly require implementersto give a physically present user complete control over Secure Boot – turn itoff, or completely control the list of keys it trusts. Another important notehere is that while the certification requirements state that the out-of-the-boxlist 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 andintentionally allow for the system to ship with any number of other trustedkeys, too.
These requirements aren’t present entirelyout of the goodness of Microsoft’s heart, or anything – they’re present inlarge part because other people explained to Microsoft that if they weren’tpresent, it’d have a hell of a lawsuit on its hands2 – but they are present.Anyone who actually understands UEFI and Secure Boot cannot possibly read therequirements any other way, they are extremely clear and unambiguous. They bothclearly intend to and succeed in ensuring the owner of a certified system hascomplete control over Secure Boot.
If you have an x86 system that claims to beWindows certified but does not allow you to disable Secure Boot, it is indirect violation of the certification requirements, and you should certainlycomplain very loudly to someone. If a lot of these systems exist then weclearly have a problem and it might be time for that giant lawsuit, but so farI’m not aware of this being the case. All the x86-based, Windows-certifiedsystems I’ve seen have had the ‘disable Secure Boot’ option in their firmwares.
Now, for ARM machines, the requirements aresignificantly more evil: they state exactly the opposite, that it must not bepossible to disable Secure Boot and it must not be possible for the systemowner to change the trusted keys. This is bad and wrong. It makesMicrosoft-certified ARM systems into a closed shop. But it’s worth noting it’sno more bad or wrong than most other major ARM platforms. Apple locks down thebootloader on all iDevices, and most Android devices also ship with lockedbootloaders.
If you’re planning to buy aMicrosoft-certified ARM device, be aware of this, and be aware that you willnot be in control of what you can boot on it. If you don’t like this, don’t buyone. But also don’t buy an iDevice, or an Android device with a lockedbootloader (you can buy Android devices with unlocked or unlockablebootloaders, still, but you have to do your research).
As far as x86 devices go, though, rightnow, Microsoft’s certification requirements actually explicitly protect yourright to determine what can boot on your system. This is good.
Recommendations
The following are AdamW’s GeneralRecommendations On Managing System Boot, offered with absolutely no guaranteesof accuracy, purity or safety.
If you can possibly manage it, have one OSper computer. If you need more than one OS, buy more computers, or usevirtualization. If you can do this everything is very simple and it doesn’tmuch matter if you have BIOS or UEFI firmware, or use UEFI-native orBIOS-compatible boot on a UEFI system. Everything will be nice and easy andwork. 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 oneOS per computer, at least have one OS per disk. If you’re reasonablycomfortable with how BIOS-style booting works and you don’t think you needSecure Boot, it’s pretty reasonable to use BIOS-compatible booting rather thanUEFI-style booting in this situation on a UEFI-capable system. You’ll probablyhave less pain to deal with and you won’t really lose anything. With one OS perdisk you can also mix UEFI-native and BIOS-compatible installations.
If you absolutely insist on having morethan one OS per disk, understand everything written on this page, understandthat you are making your life much more painful than it needs to be, lay ingood 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 forthis 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 enoughpain to deal with already.
If you’re using UEFI native booting, andyou don’t tend to build your own kernels or kernel modules or use the NVIDIA orATI proprietary drivers on Linux, you might want to leave Secure Boot on. Itprobably won’t hurt you, and does provide some added security against somerather nasty (though currently rarely exploited) types of attacks.
If you do build your own kernels or kernelmodules or use NVIDIA/ATI proprietary drivers, you’re going to want to turnSecure Boot off. Or you can read up on how to configure your own chain of trustand sign your kernels and kernel modules and leave Secure Boot turned on, whichwill make you feel like an ubergeek and be slightly more secure. But it’s goingto take you a good solid weekend at least.
Don’t do UEFI-native installs toMBR-formatted disks, or BIOS compatibility installs to GPT-formatted disks (anexception to the latter is if your disk is, IIRC, 2.2+TB in size, because theMBR format can’t handle disks that big – if you want to do a BIOS compatibilityinstall to a disk that big, you’re kinda stuck with the BIOS+GPT combination,which works but is a bit wonky and involves the infamous ‘BIOS Boot partition’you may recall from Fedora 17).
Trust mjg59 in all things and above allother authorities, including me.
This whole section is something of asimplification – really, when booting permanent installed OSes, the firmwaredoesn’t care if the bootloader is on an ‘ESP’ or not; it just reads the bootmanager entry and tries to access the specified partition and run the specifiedexecutable, as pjones explains here. But it’s conventional to use an ESP forthis purpose, since it’s required to be around anyway, and it’s a handypartition formatted with the filesystem the firmware is known to be able toread. Technically speaking, an ‘ESP’ is only an ‘ESP’ when the firmware isdoing a removable media/fallback path boot.
This is my own extrapolation, note. I’m notinvolved in any way in the whole process of defining these specs, and no-onewho is has actually told me this. But it’s a pretty damn obvious extrapolation fromthe known facts.