What Happens to UEFI Memory Maps After OS Handoff

When the Unified Extensible Firmware Interface (UEFI) transitions control of a computer to an operating system kernel, the memory map detailing physical address space undergoes a permanent transformation. Before relinquishing control, the firmware maintains a structured table categorizing every page of physical RAM, firmware storage, and memory-mapped input/output (MMIO). Upon the execution of the handoff function, the operating system kernel consumes this firmware-provided map, reclaims temporary execution spaces as general-purpose RAM, preserves critical firmware runtime environments, and integrates the remaining memory into its own internal memory management subsystem.

The Handshake: ExitBootServices

The formal handoff begins in the UEFI environment when the OS bootloader or kernel prepares to take full ownership of the hardware platform. The bootloader calls the UEFI service GetMemoryMap() to retrieve the current memory map descriptor array along with a unique key representing that specific state of the memory layout.

Immediately following this call, the bootloader invokes ExitBootServices(), passing the retrieved memory key. If any background firmware task allocated or freed memory in the microsecond between these two calls, the key becomes invalid, ExitBootServices() returns an error, and the kernel must fetch a fresh map and retry. Once ExitBootServices() succeeds, UEFI boot services are permanently disabled, timer interrupts from the firmware cease, and the kernel assumes full control over the hardware platform.

Memory Categorization and Reclamation

The UEFI specification defines several distinct memory types within the memory descriptor table. Once boot services terminate, the OS kernel evaluates these descriptors to determine what can be immediately recycled, what must be temporarily held, and what must be permanently protected:

  • Boot Services Memory (EfiBootServicesCode, EfiBootServicesData): During platform initialization, UEFI uses these pages to run drivers, protocol handlers, and pre-boot initialization logic. After ExitBootServices() finishes, these regions are no longer needed. The OS reclaims this memory, converting thousands of megabytes of boot-time structures directly into free, usable system RAM.
  • Loader Memory (EfiLoaderCode, EfiLoaderData): Used primarily by the bootloader binary and its loaded artifacts (such as initial RAM disks or kernel staging areas). Once the kernel extracts its payload and establishes initial structures, this memory is also freed into the general memory pool.
  • Conventional Memory (EfiConventionalMemory): This is unused RAM that has never been occupied by firmware structures. The operating system immediately registers these regions as usable physical memory frames.
  • ACPI Regions (EfiACPIReclaimMemory, EfiACPIMemoryNVS): ACPI Reclaim memory contains the ACPI tables (DSDT, SSDT, MADT, etc.). The OS protects this space until its ACPI driver parses the hardware topology; afterward, it can reclaim the pages. Non-Volatile Sleep (EfiACPIMemoryNVS) memory must be preserved entirely across all power states and cannot be overwritten.
  • Runtime Services Memory (EfiRuntimeServicesCode, EfiRuntimeServicesData): These regions house the firmware code and data structures needed while the OS is operating. Functions such as reading and writing UEFI NVRAM variables, initiating system resets, or handling capsule updates reside here. The operating system must never overwrite these pages.

Transition to Virtual Addressing

In the pre-boot environment, UEFI typically executes with a 1:1 identity map, where virtual addresses equal physical addresses. Modern operating systems do not operate this way; they set up sophisticated, multi-level paging structures to enforce security boundaries, address isolation, and kernel space virtualization.

To allow UEFI runtime services to function alongside the operating system:

  1. The kernel constructs page tables mapping the physical EfiRuntimeServicesCode and EfiRuntimeServicesData ranges into designated virtual memory addresses (often within dedicated kernel address space).
  2. The kernel calls the UEFI runtime function SetVirtualAddressMap(), passing an array of descriptors specifying the new virtual address for each runtime memory region.
  3. The UEFI firmware updates its internal pointer tables to point to these newly assigned virtual locations.

After this transition, the OS can invoke runtime firmware calls safely using its virtual paging scheme without risking memory collisions.

Integration into Operating System Allocators

Once memory ranges are segregated, the kernel initializes its own page allocators (such as the buddy allocator in Linux or the PFN database in Windows). Every physical page deemed usable is converted into a management struct that tracks page allocation, cache attributes, and reference counts.

The raw UEFI memory map itself is preserved in kernel memory rather than discarded. Operating systems archive the initial map to support hardware debugging, facilitate crash dumps, and expose platform topology to user-space utilities (such as via /sys/firmware/memmap or /sys/firmware/efi on Linux). Once physical memory initialization is finalized, the pre-boot environment ceases to exist, and all subsequent memory allocation is dictated solely by the kernel.