How the UEFI BDS Phase Selects an OS Boot Loader

The Boot Device Selection (BDS) phase is the final stage of the Unified Extensible Firmware Interface (UEFI) initialization environment before control transfers to an operating system. During this phase, the firmware evaluates hardware and policy configuration, consults globally defined non-volatile variables, and identifies the correct operating system loader binary to execute. This article details the sequential mechanisms BDS uses to determine, validate, and launch the designated OS loader from connected storage media.

Initialization of the BDS Architectural Protocol

Once the Driver Execution Environment (DXE) phase completes hardware initialization and creates the required core protocol interfaces, it invokes the BDS Architectural Protocol (EFI_BDS_ARCH_PROTOCOL). BDS initializes the platform console devices (such as displays and keyboards) and connects drivers to target block devices (like NVMe, SATA, and USB controllers) using the UEFI Driver Model, ensuring the file systems containing OS loaders are accessible.

Querying NVRAM Boot Variables

The core decision-making process in BDS relies on specific global environment variables stored in non-volatile RAM (NVRAM):

  1. BootNext: BDS checks if this optional variable is set. It contains a single 16-bit integer pointing directly to an override boot option (e.g., Boot0003). If present, the firmware prioritizes this boot option and deletes the BootNext variable immediately to prevent boot loops.
  2. BootOrder: If BootNext does not exist or fails to boot, BDS reads BootOrder. This variable contains an ordered array of 16-bit integers (e.g., 0001, 0002, 0000) representing the user- or vendor-defined priority of available boot candidates.
  3. Boot####: For each index defined in BootOrder, BDS looks up the corresponding Boot#### variable (e.g., Boot0001). This variable maps to an EFI_LOAD_OPTION structure, which contains:
    • Attributes indicating whether the entry is active or hidden.
    • A human-readable description (e.g., "Windows Boot Manager" or "ubuntu").
    • An EFI_DEVICE_PATH_PROTOCOL structure pointing directly to the partition GUID and the file path of the OS loader (such as \EFI\Microsoft\Boot\bootmgfw.efi).
    • Optional platform-specific arguments passed to the loader.

Device Path Resolution and Media Verification

BDS processes each entry in BootOrder sequentially:

  1. Path Traversal: BDS parses the EFI_DEVICE_PATH_PROTOCOL inside the active Boot#### option, resolving hardware buses, disk partitions (matched via GPT partition UUIDs), and target directories.
  2. File Availability: BDS interacts with the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on the target partition (the EFI System Partition, or ESP) to verify that the file exists and is readable.
  3. Failure Handling: If the target storage device is disconnected, the partition is missing, or the binary is not found, BDS abandons that entry and immediately proceeds to the next candidate in BootOrder.

The Default Fallback Boot Path

When non-volatile entries are invalid, exhausted, or a removable medium (such as a USB flash drive) without a pre-registered NVRAM entry is inserted, BDS falls back to the default removable media path defined by the UEFI specification:

\EFI\BOOT\BOOT<ARCH>.EFI

The architecture token (<ARCH>) varies based on the target processor:

  • x86-64: \EFI\BOOT\BOOTX64.EFI
  • AArch64 (ARM 64-bit): \EFI\BOOT\BOOTAA64.EFI
  • IA-32: \EFI\BOOT\BOOTIA32.EFI
  • RISC-V 64-bit: \EFI\BOOT\BOOTRISCV64.EFI

If a file exists at this path on a formatted FAT32 partition, BDS treats it as a valid OS loader candidate.

Security Validation and Execution

Once a valid loader binary path is identified—either through NVRAM variables or the default fallback path—BDS executes the following operations:

  1. Image Loading: BDS invokes the UEFI Boot Service gBS->LoadImage(). This loads the PE/COFF-formatted executable into system memory and assigns it an image handle.
  2. Secure Boot Verification: If UEFI Secure Boot is enabled, the firmware's security subsystem intercepts execution to verify the binary against the authorized signature database (db), ensuring it is not revoked in the forbidden database (dbx). If verification fails, BDS aborts loading and advances to the next entry in BootOrder.
  3. Execution: If verification succeeds, BDS calls gBS->StartImage(). This passes execution control to the operating system loader, concluding the role of the BDS phase.