The EFI boot process.

You've come to this page because you've asked a question similar to the following:

What is the boot process employed by EFI (Extensible Firmware Interface) machine firmware?

This is the Frequently Given Answer to such questions.

Bootstrapping on EFI involves a boot manager that is built in to the firmware. EFI systems do not rely upon bootstrap programs stored in boot records (VBRs or MBRs) at all. The firmware knows how to read a partition table and understands the FAT filesystem format. (IBM PC compatible firmware does neither.) A designated partition, that is formatted with the FAT filesystem format and identified with a specific well-known partition type, is known as the EFI System Partition. (The EFI System Partition is a true system volume that is identified by its type code in the partition table, not a Poor Man's equivalent that is guessed at like Microsoft's System Reserved Partition is.) It contains boot loader programs, which are EFI executable programs that are loaded and run by the EFI boot manager.

EFI executable programs are standalone programs, that use only machine firmware services and that do not require an underlying operating system in order to run. They can be either operating system boot loaders or "pre-boot" maintenance/diagnosis programs.

The EFI boot manager

The details of the EFI boot manager are up to the firmware implementor, but all boot managers are configured using well-known EFI variables, which are publicly defined and documented mechanisms for holding firmware configuration data. Boot managers are required to inspect these EFI variables and behave accordingly. The main variable is the BootOrder EFI variable. And there are two primary use cases:

In many ways the EFI boot process is much the same as the ARC boot process: There's a boot manager built in to the firmware, that uses a database comprising a set of firmware variables (alterable by operating system installation and utility programs and with a public and well defined structure), that presents a list of options from which the user chooses, which results in a loader program to run and some options to pass to it.

The differences lie in the details. EFI device paths are more expressive than ARC paths (which as anyone who has fiddled with BOOT.INI on Windows NT versions 4 or 5 will know, have an obscure and not very intuitive format) and encode hardware device locations more accurately (modulo some strange ideas that EFI has about SCSI). The EFI boot manager has the option to boot to a command interpreter, the "EFI Shell". And there's a well defined firmware interface that has a well-defined extension mechanism for adding things such as extra filesystem drivers to allow boot-time access to disc volumes formatted with filesystem formats other than FAT.

Boot loaders

By convention, all of the boot loaders for operating systems are stored in the EFI system partition on a partitionable DASD, in a vendor-specific subdirectory of the \EFI\ directory.

Windows NT versions 5.x

For the 64-bit versions of Windows NT 5.x, the EFI boot loader is \EFI\Microsoft\WINNT50\IA64LDR.EFI (sometimes \EFI\Microsoft\WINNT50C\IA64LDR.EFI), which comprises NTLDR, the Windows NT boot loader that loads and executes the Windows NT kernel from files in the Windows boot volume.

64-bit versions of Windows NT 5.x use EFI as it was designed to be used.

Windows NT versions 6.x

For Windows NT 6, the EFI boot loader is \EFI\Microsoft\Boot\Bootmgfw.efi, which is the Microsoft Boot Manager — another boot manager, which presents a second menu of boot options, read from a database file in a Microsoft-proprietary format, which in turn list boot loader programs to invoke and options to pass to them.

Windows NT 6 needlessly duplicates the functionality of the EFI boot manager, and needlessly makes a user-visible distinction between all other operating systems (listed on the first boot manager menu, which Microsoft configures to be displayed for only 2 seconds in order to, in Microsoft's own words, "make it easier" for users) and Windows NT (listed on the second boot manager menu).

Linux

For the 64-bit versions of Linux, the EFI boot loader is either \EFI\RedHat\elilo.efi or \EFI\SuSE\elilo.efi, which comprises a modified version of LILO, the Linux boot loader that loads and executes the Linux kernel from files in the system volume.

ELILO, like the Microsoft Boot Manager, contains a second level of boot options, held in a separate elilo.conf configuration file, rather than integrating support for such multiple boot options into the EFI boot loader and EFI variables, as it should. Unlike the Microsoft Boot Manager, however, ELILO is a boot loader, incapable of loading any other operating system but Linux (the different boot options merely allowing one to specify which Linux kernel image file to use and various options specific to the Linux kernel such as the ramdisc size), not a boot manager, and so does not needlessly duplicate all of the functionality of the EFI boot manager.

HP/UX

For HP-UX, the EFI boot loader is \EFI\HPUX\hpux.efi, which loads and executes the HP-UX kernel from an image file in the system volume (e.g. /vmlinux). The HP-UX boot loader also comprises an interactive shell, although the EFI Shell that comes with the EFI firmware provides much the same functionality.

How Apple makes even Microsoft seem well-behaved and conformant

Apple ignores or subverts large parts of the EFI specification on its Intel Macintoshes. The EFI System Partition is empty and unused, and the EFI boot manager is obscured by an Apple boot loader that is executed before it.

The Apple EFI firmware understands the HFS+ filesystem format, in addition to the FAT filesystem format mandated by the EFI specification. Apple's firmware boot loader reads the value of a variable stored in NVRAM. This can either point to a disc partition or to a specific file, depending from whether one has "blessed" a disc partition or a file/directory using the bless utility. (Blessing a directory is a shorthand for copying a platform-specific boot loader file into that directory and then blessing the file.)

If the value in NVRAM points to a disc partition, then the Apple boot loader assumes that this is an HFS+ formatted volume. HFS+ contains a file ID pointer in its volume header that points to a boot file. The Apple boot loader reads the HFS+ volume header, and loads and runs the indicated file as an EFI application. By default, this is /System/Library/CoreServices/boot.efi, the boot loader for MacOS X.

If the value in NVRAM points to a specific file, that is the EFI executable that the Apple boot loader loads at boot, ignoring what any HFS+ volume headers may contain. One such file is xom.efi, an alternative EFI operating system boot loader application that loads Windows NT XP on Intel Macintoshes.

If, in either case, the EFI application is non-graphical, its user interface won't be seen, because the Apple boot loader switches the display to graphical mode. If the application exits, returning to the firmware, the EFI boot manager is finally invoked. But since the EFI boot manager has a textual user interface, its user interface will not be visible, either. (A TextMode.efi EFI application is freely available that simply switches the display back to text mode and returns to the firmware.)


© Copyright 2006,2011 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.