How UEFI Passes System Tables to the OS Kernel

During the boot process, the Unified Extensible Firmware Interface (UEFI) delivers essential hardware and platform descriptions to the operating system kernel through a central pointer structure called the EFI_SYSTEM_TABLE. This table contains an array of vendor- and standard-defined pointers paired with Globally Unique Identifiers (GUIDs), allowing the bootloader or kernel stub to locate critical system tables—most notably ACPI (Advanced Configuration and Power Interface) and SMBIOS (System Management BIOS). By inspecting these structures and capturing the memory map before terminating UEFI boot services, the operating system secures the physical addresses required to manage hardware after firmware handoff.

The Role of the EFI_SYSTEM_TABLE

When the UEFI boot manager loads an operating system's EFI application (either a dedicated bootloader like GRUB or a kernel compiled with an embedded EFI stub), it invokes the executable's entry point using two primary arguments:

  1. EFI_HANDLE ImageHandle: The firmware-assigned handle for the loaded image.
  2. EFI_SYSTEM_TABLE *SystemTable: A pointer to the primary control structure of the UEFI environment.

The EFI_SYSTEM_TABLE contains pointers to standard console I/O interfaces, runtime service function tables, boot service function tables, and an array named ConfigurationTable.

Locating Tables via the Configuration Table Array

The configuration table array is the definitive bridge for passing system description tables to the operating system. Within the EFI_SYSTEM_TABLE, two members govern this interface:

  • NumberOfTableEntries: An integer specifying the total count of registered configuration tables.
  • ConfigurationTable: A pointer to an array of EFI_CONFIGURATION_TABLE structures.

Each entry in the ConfigurationTable array consists of two fields:

typedef struct {
    EFI_GUID VendorGuid;
    VOID     *VendorTable;
} EFI_CONFIGURATION_TABLE;

To locate specific system tables, the bootloader or kernel iterates through the ConfigurationTable array and compares each VendorGuid against known, standardized GUIDs:

  • ACPI 2.0 and later: EFI_ACPI_20_TABLE_GUID ({8868e871-e4f1-11d3-bc22-0080c73c8881}). The associated VendorTable pointer directly references the ACPI Root System Description Pointer (RSDP).
  • ACPI 1.0: ACPI_10_TABLE_GUID ({eb9d2d30-2d88-11d3-9a16-0090273fc14d}).
  • SMBIOS 3.x: SMBIOS3_TABLE_GUID ({f2fd1544-9794-4a2c-992e-e5bbcf20e394}).
  • Device Tree (on ARM/RISC-V systems): DEVICE_TREE_GUID ({b1b626f4-2e62-47a8-a764-a690e82c5a3d}).

Once a match is found, the software extracts the VendorTable physical address, which points to the base of the targeted specification's root table (such as the ACPI RSDP, which subsequently links to the XSDT and individual ACPI tables like FADT, MADT, and DSDT).

Memory Preservation and the UEFI Memory Map

System description tables are generated by firmware and stored in standard system RAM. To prevent the operating system from overwriting these tables when it assumes memory management duties, UEFI classifies their memory ranges under specific types:

  • EfiACPIReclaimMemory: Holds tables such as the RSDP, XSDT, and other static ACPI tables. The OS can reclaim this memory after it reads and parses the tables during early boot.
  • EfiACPIMemoryNVS: Firmware-reserved memory used for ACPI Non-Volatile Storage (such as hardware registers or ACPI operational regions), which the OS must never overwrite.
  • EfiRuntimeServicesData / EfiRuntimeServicesCode: Preserved for OS-firmware communication post-handoff (e.g., updating EFI NVRAM variables or executing system resets).

Before transitioning control, the bootloader calls the boot service function GetMemoryMap() to obtain the complete layout of physical memory, including which regions contain these protected descriptor tables.

The Handoff Transition: ExitBootServices

Firmware control ends when the bootloader calls ExitBootServices(). This call requires the current memory map key to ensure memory layout integrity:

  1. The bootloader calls GetMemoryMap().
  2. The bootloader calls ExitBootServices(ImageHandle, MapKey).
  3. UEFI invalidates all boot services functions, dismantles memory allocation services, and turns over complete control of system hardware to the OS.

Because the UEFI ConfigurationTable array and boot-time service functions are no longer guaranteed to exist after ExitBootServices(), the OS loader must extract the physical pointers to the description tables prior to this call.

Forwarding Pointers to the Kernel

Modern kernels handle the acquired table pointers in one of two ways:

  • Direct Boot via EFI Stub: If the kernel contains an EFI stub (common in modern Linux and Windows kernels), the kernel acts as its own UEFI application. It parses the EFI_SYSTEM_TABLE directly, reads the GUID array, extracts the ACPI RSDP and SMBIOS pointers, calls ExitBootServices(), and directly passes the physical pointers to its early initialization subsystems.
  • Traditional Bootloaders: If an external bootloader (such as GRUB) executes the handoff, it parses the ConfigurationTable while boot services are active. It then places the extracted physical addresses (e.g., the ACPI RSDP pointer) into an architecture-specific boot parameters structure (such as the boot_params structure on x86-64 Linux) or passes them as kernel command-line arguments. When the OS kernel unpacks these parameters, it maps the physical addresses into its virtual address space and proceeds to initialize system devices.