How UEFI Multi-Boot Managers Handle OS Menus

In a native Unified Extensible Firmware Interface (UEFI) environment, multi-boot managers display operating system selection menus by executing early pre-boot protocols before any operating system kernel is loaded. Unlike legacy BIOS systems that relied on master boot records and raw disk sectors, UEFI multi-boot managers leverage standardized firmware services, NVRAM variables, and the EFI System Partition (ESP) to render visual menus, capture user input, and launch the chosen operating system. This article explains the underlying mechanisms UEFI multi-boot managers use to discover installed environments, display graphical and text interfaces, and pass execution control to the selected OS.

The Role of the EFI System Partition and NVRAM

The foundation of UEFI booting begins with the EFI System Partition (ESP), a dedicated FAT32 partition containing .efi executable binaries. When a computer powers on, the UEFI firmware reads non-volatile RAM (NVRAM) variables—specifically BootOrder and Boot#### entries—to determine which bootloader to execute first.

In a multi-boot setup, a primary boot manager (such as GRUB, rEFInd, or systemd-boot) is typically registered as the first entry in this sequence. Once the UEFI firmware initializes the hardware, it calls the LoadImage() and StartImage() boot services to transfer execution to the multi-boot manager's binary on the ESP.

Rendering Menus via UEFI Protocols

Legacy BIOS bootloaders relied on interrupt calls (such as INT 10h) and limited VGA modes to display text interfaces. UEFI replaces these low-level calls with standardized protocols that boot managers use to build menus:

  • Graphics Output Protocol (GOP): GOP provides a platform-independent way to access the display hardware’s linear frame buffer. Boot managers like rEFInd and modern GRUB themes use GOP to render high-resolution graphical icons, backgrounds, and scaled fonts.
  • Simple Text Output Protocol: For lightweight or minimalist menus (such as systemd-boot or text-mode GRUB), this protocol allows managers to draw standard character grids and handle basic color attributes without managing pixel buffers directly.
  • Simple Text Input Protocol: To navigate the menu, the boot manager uses this protocol to poll for keystrokes or accept enter commands from keyboards initialized by the firmware's Human Interface Device (HID) drivers. Some managers also support touch inputs via the Absolute Pointer Protocol.

Discovering and Managing Operating System Entries

Multi-boot managers determine which operating systems to display using one of two methods: static configuration or dynamic filesystem discovery.

Static Configuration

Traditional managers, such as GRUB, read a centralized text file (like grub.cfg) located within the ESP or a designated Linux partition. This configuration dictates the menu timeout, visual theme, and exact hardware paths (UUIDs and partition numbers) pointing to the kernels or secondary bootloaders to run.

Dynamic Discovery and Boot Loader Specification (BLS)

Modern managers, such as rEFInd and systemd-boot, dynamically query UEFI file system protocols (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) at startup.

  • Auto-detection: Tools like rEFInd scan all readable partitions for recognizable files, such as Microsoft’s bootmgfw.efi, Apple’s bootloader, or Linux kernels with integrated EFI stubs.
  • Boot Loader Specification: Many modern Linux distributions place discrete configuration snippets inside /loader/entries/. Boot managers read these drop-in files to automatically generate menu options without requiring manual script updates whenever a kernel is installed or removed.

Secure Boot Integration

When UEFI Secure Boot is active, firmware verifies cryptographic signatures before executing any EFI binary. Multi-boot managers handle this workflow through signed intermediate binaries, commonly known as a "shim."

The firmware verifies the shim using certificates embedded in its hardware database (DB). Once running, the shim exposes a secondary verification protocol (Machine Owner Key, or MOK) that validates the multi-boot manager and its subsequent OS kernels. If an entry fails cryptographic verification, the menu can prevent the entry from executing or alert the user.

Transferring Control to the Target OS

Once the user selects an operating system from the menu, the multi-boot manager executes the handoff:

  1. Kernel Direct Boot (EFISTUB): For Linux kernels compiled with EFI boot stub support, the boot manager treats the kernel itself as an EFI binary, loading it directly into memory along with an initial RAM disk (initramfs) and kernel command-line arguments.
  2. Chainloading: For operating systems with dedicated bootloaders (like Windows Boot Manager or macOS), the manager loads the target .efi application via LoadImage() and executes it with StartImage().
  3. ExitBootServices: The final operating system kernel eventually calls the UEFI ExitBootServices() function, which terminates the firmware's pre-boot environment, frees the memory used by the boot manager and firmware drivers, and gives the operating system full control of the computer's hardware.