UEFI HOB List: PEI to DXE Hand-Off Explained

In the Unified Extensible Firmware Interface (UEFI) architecture, the Hand-Off Block (HOB) list serves as the vital communication bridge between the Pre-EFI Initialization (PEI) phase and the Driver Execution Environment (DXE) phase. Because the PEI phase executes in an environment with limited resources and initializes the system's physical memory, it must transfer its discoveries, system states, and configuration data to the DXE phase, which operates in a standard, fully initialized memory environment. This article examines the architectural purpose, key components, and fundamental significance of the HOB list in ensuring a seamless UEFI boot sequence.

The Architectural Gap Between PEI and DXE

During early platform initialization, the PEI phase executes under severe constraints, often using processor cache as temporary RAM (Cache-as-RAM or CAR). The primary goal of PEI is to configure core platform hardware, detect and initialize system RAM, and locate the DXE core.

Once physical RAM is initialized, the PEI phase must transition execution to the DXE phase. However, PEI’s temporary execution environment is torn down during this process, destroying the PEI stack and transient data. The HOB list solves this fundamental problem: before exiting, PEI creates the HOB list in newly discovered, permanent system RAM to pass critical platform states forward to DXE.

Key Functions and Significance of the HOB List

The HOB list is an array of data structures allocated contiguously in memory, terminated by an end-of-list marker. Its significance is defined by several core functions:

• Describing the Physical Memory Map: The DXE phase has no inherent knowledge of the platform's physical memory layout. PEI uses Resource Descriptor HOBs to define system memory, memory-mapped I/O, reserved regions, and firmware storage. Without this data, the DXE memory manager cannot initialize the system's permanent memory allocation tables.
• Locating Firmware Volumes: DXE consists of independent modular drivers that must be discovered and executed. PEI passes Firmware Volume (FV) HOBs, which point to the flash regions containing the DXE drivers and their dependency expressions, allowing the DXE Dispatcher to begin execution.
• Communicating Boot Mode: Platforms boot under different circumstances, such as a cold boot, a warm reset, a firmware update, or an ACPI S3 resume. Boot Mode HOBs inform the DXE phase of the current path so it can bypass redundant driver initialization during resume states or enter maintenance modes when required.
• Encapsulating Silicon and Platform Configurations: Modern chipsets require early silicon initialization data to be available later in the boot process. Through GUID Extension HOBs, hardware vendors can pass proprietary data structures—such as memory timings, CPU microcode status, and platform-specific policies—directly from silicon-specific PEI modules (PEIMs) to their corresponding DXE drivers.

Unidirectional Flow and Data Integrity

Architecturally, the HOB list enforces a strictly unidirectional flow of information. The PEI phase produces the HOB list, and the DXE phase consumes it.

Once the DXE core takes control, the HOB list becomes essentially read-only. DXE modules can query the HOB list using the HOB Services Table to parse platform configurations, but they do not use HOBs for dynamic inter-driver communication. Instead, DXE relies on UEFI Protocols. Eventually, the DXE phase converts necessary HOB data into standard UEFI Memory Maps and runtime configurations, ensuring that lower-level hardware discovery is safely transitioned into standard UEFI interfaces before handing control to the operating system bootloader.