UEFI Configuration Tables in Hardware Description

During the Unified Extensible Firmware Interface (UEFI) boot phase, configuration tables serve as the standardized mechanism for firmware to advertise and hand off platform hardware descriptions to the operating system loader. By aggregating diverse data structures—such as ACPI, SMBIOS, and Device Trees—into a centralized array of globally unique identifier (GUID) and pointer pairs, UEFI configuration tables decouple the underlying platform hardware specifics from the operating system, ensuring seamless hardware discovery and boot initialization.

Structure of UEFI Configuration Tables

At the core of the UEFI architecture is the EFI_SYSTEM_TABLE, which acts as the primary data structure passed to the operating system bootloader. Embedded within this structure is an array of EFI_CONFIGURATION_TABLE entries. Each entry consists of two fundamental components:

  • VendorGuid: A 128-bit GUID that explicitly defines the specification, format, and purpose of the table (for example, the ACPI 2.0 table GUID or the SMBIOS table GUID).
  • VendorTable: A 64-bit physical memory pointer referencing the base address where the corresponding hardware description data structure resides in memory.

Exposing Standardized Hardware Interfaces

Modern hardware architectures rely on diverse frameworks to describe non-enumerable buses, platform controllers, and system topologies. UEFI configuration tables act as the delivery vehicle for these frameworks:

  • ACPI (Advanced Configuration and Power Interface): For x86 and enterprise ARM systems, UEFI firmware builds ACPI tables (DSDT, SSDT, MADT, etc.) during the Driver Execution Environment (DXE) phase. The firmware places the pointer to the Root System Description Pointer (RSDP) into a configuration table entry using standard ACPI GUIDs. This allows the OS to discover processor cores, interrupt controllers, and power states.
  • SMBIOS (System Management BIOS): Configuration tables expose the SMBIOS entry point, providing the OS with data regarding chassis, motherboard, BIOS revision, and installed RAM modules.
  • Flattened Device Tree (FDT): In embedded systems and non-ACPI ARM/RISC-V platforms, the firmware registers an FDT pointer via its assigned GUID. The kernel parses this Device Tree blob directly from memory to enumerate memory-mapped peripherals and clock trees.

The Registration and Handoff Lifecycle

The delivery of hardware descriptions via configuration tables follows a strict sequence across the UEFI boot phases:

  1. Generation (PEI/DXE Phases): Platform-specific initialization drivers detect hardware configurations, allocate runtime or boot-service memory, and populate the relevant hardware tables.
  2. Registration: Firmware components invoke the InstallConfigurationTable() boot service. This service either appends a new GUID-pointer mapping to the array or updates an existing entry.
  3. Handoff (BDS Phase to OS): The Boot Device Selection (BDS) phase loads the target OS bootloader, passing a pointer to the EFI_SYSTEM_TABLE.
  4. Consumption: The OS bootloader scans the configuration table array, matches the GUIDs against its supported hardware frameworks (such as ACPI or FDT), and saves the memory addresses.
  5. Runtime Transition: When ExitBootServices() is called, boot-time services terminate, but tables residing in designated runtime memory or ACPI reserved memory persist, enabling the operating system kernel to maintain full control over the platform's hardware topology and power management.