UEFI guide

[val]

@alpopa

The purpose of a bootloader is to load the kernel image into memory and to transfer the control to it. UEFI is not an exception. How do you imagine the UEFI loader is embedded into Linux kernel, if at the stage of executing of UEFI bootloader the kernel is not yet loaded in memory? And what is the purpose of the bootloader if during its execution (it is already loaded in memory) the Linux kernel (that is assumed embedded into it) is in memory as well? Linux NEVER installs kernel or initramfs (each of several MB) into ESP partition. On the other hand, the GRUB bootloader stage 0 is installed here (other stages are installed in Linux partition). The code of this stage is really tiny. For comparison: when GRUB is installed on MBR systems, this stage is completely fits into 512 Bytes of MBR (i.e. 4096 bits), and there is plenty of space there yet.

val:

1. They call it “efi boot stub”. From their scarce documentation (Documentation/x86/boot.txt), we learn:

**** EFI HANDOVER PROTOCOL

This protocol allows boot loaders to defer initialisation to the EFI
boot stub. The boot loader is required to load the kernel/initrd(s)
from the boot media and jump to the EFI handover protocol entry point
which is hdr->handover_offset bytes from the beginning of

Even having separate OSL, it can “defer initialisation” to the embedded into the kernel “efi boot stub”, which is basically yet another OSL.

2. From the their file Documentation/x86/x86_64/uefi.txt, line 26:

• Create a VFAT partition on the disk
• Copy the following to the VFAT partition:
  elilo bootloader with x86_64 support, elilo configuration file,
  kernel image built in first step and corresponding
  initrd. Instructions on building elilo and its dependencies
  can be found in the elilo sourceforge project.
• Boot to EFI shell and invoke elilo choosing the kernel image built
  in first step.

As of what the purpose, they probably know it. I was talking about ARM though, because on x86 they use some loaders but still require putting their kernel and stuff into what they call VFAT partition.
(Added later). On ARM (64 bit), there is also that stub, which is at the beginning of their gigantic kernel, basically a PE file fused with everything else (see Documentation/arm64/booting.txt). for 64 bit ARM, they devised a special “image” and its header has a field pointing to the “stub”. and for now, on ARM SBCs, UEFI is not broadly used, but the approach is the same: you have a small (~100 MB) “boot” volume and linux image & Co reside there (or, as a bonus of the crappy building process, for some vendors, - a bunch of images, initrds, and device trees). now uboot loads linux image & Co through a special linux specific command “booti”, but uboot is getting into UEFI and has something implemented of it already. So uboot has two ways of transfering control to it - jumping into code of the header (see referenced “documentation” above), or, - calling the entry poing of the “efi boot stub”. and if that stub makes use of UEFI, it will call uboot back (through the System Table passed to it). I don’t know which way they use now, OpenBSD for ARM e.g. already requires UEFI. Now you see, that in fact, linux turns itself into a UEFI OSL that is loaded (as a whole) by uboot (that is “kinda” UEFI). This is not UEFI compatible. They need to provide yet a separate OSL, that would be messing around with their invented wheels (arm64 “image”). uboot follows linux obediently keeping on on the antipattern of forging linux specific commands, but a normal UEFI implementation won’t do this. Then, you will need elilo, grub or whatever. but still, this doesn’t change the fact linux has internally embedded UEFI OSL. Yet once - OSL is a UEFI application that calls ExitBootSevices(). Guess who does this if “efi boot stub” has been called? The only thing why linux image can’t be loaded directly by UEFI is because UEFI expects a proper PE file, whereas linux has it somewhere behind those “headers” inside. Anyway, very often linux images end up laying inside “boot” volumes of any kind. Don’t expect ESP won’t suffer the same fate. I don’t, so I’d allocate a little bit more than 32 MB. just in case.

@alpopa

OSL (OS Loader, or stage 1 boot) resides in the first sector of partition where OS is installed, not in ESP partition, which is shared across all the OSes. Its size is larger, but is not shared and occupes no space in ESP.

Not in the UEFI context, What you retell is the BIOS way (MBR code, boot sector code etc). UEFI ignores BIOS MBR code and any boot sector code completely. They are not used, you are wrong. There is no “stages” of loaders in UEFI either. Instead, there is notion of an OS Loader - a special type of UEFI application (it’s specialty is in that normally it doesn’t return to UEFI, uses ExitBootServices()). It’s a payload of UEFI, it loads it into memory (according to the load option related to it) and transfers control to it. OSL is a PE file that is most expected to reside in the ESP just like any executable file. But this file may reside on other volumes, where FW can reach to. For example the Boot Manager “boot from file” option is an example. There could be non-ESP FAT volumes from where you could load it. Or even non-ESP non-FAT volumes! In the latter case, a UEFI driver is needed, that “materializes” that file system and installs the FS protocol on it. What is invariant - UEFI operates with PE files as its payloads. No “boot sectors” or alike.

@alpopa

Now, let do some math. The GPT standard allows up to 128 partitions in default partition scheme (it can be modified to almost unlimited number though). I personally use 7 OSes on my desktop, but usually people are using no more than 2-3 OSes installed. Let us imagine some extremist who installs 127 OSes (1 partition is reserved for ESP). Each has the stage 0 bootloader of less than 1 MB, total is less than 127 MB in this extreme use-case. Microsoft recommends 256 MB for ESP partition, and this is more than enough. 32 MB is absolutely sufficient for almost all use-cases. Of course, people are free to keep their movies of several GB in ESP partition, but it is out of its purpose.

Actually, there is no limit on the partition count, the specification just requires the minimum size for the Partition Array, to be able to create this minimum number of partitions. It’s not “default”. I’d say, that correlating with the disk size, would be a normal way of the decision, when creating GPT on it.
Your math forgets about:

• bitmap images for logos (with freaking animation! ), other similar resources (bitmap fonts maybe, because there are moments when UEFI Boot Services aren’t available already, but the kernel isn’t ready yet to draw the screen, and you still want to show something, this is graphics, its resources can take a bit of space)
• utilities (memory testing, storage testing etc)
• backup files used by OSLs and utilities during their operations
• configuration files
• logs of different kinds

finally, again - linux all in one pile of it.

As of naming conventions. It’s not about preventing “malicious” users to do bad things. Nor about providing an “ubreakable” way of organizing ESP. For this there is “teh security”. It’s about avoiding clashing with others. I referenced the chapter of the specification, where it’s described better, than I did. The intention of this is for well behaved OS vendors to have their own apartment in the UEFI house, that lets them integrate into platform the best way.