UEFI Boot Services vs Runtime Services Memory Reclamation

In Unified Extensible Firmware Interface (UEFI) architecture, memory management distinguishes between services needed only during the platform initialization phase and those required throughout the operating system's entire lifecycle. The fundamental difference regarding memory reclamation is that all memory consumed by UEFI Boot Services is relinquished and repurposed as free system RAM once the operating system kernel assumes control. In contrast, memory assigned to UEFI Runtime Services remains strictly protected, permanently reserved, and mapped into the operating system's address space to support ongoing platform operations.

The Role of ExitBootServices()

The reclamation boundary between Boot Services and Runtime Services is defined by the firmware call ExitBootServices().

During the pre-boot environment, the UEFI firmware and the OS bootloader rely heavily on Boot Services for hardware initialization, device discovery, and loading binaries. Once the OS loader has gathered the system memory map and loaded the kernel into memory, it invokes ExitBootServices(). This critical function signals the firmware that the boot phase is complete, terminating all Boot Services and transferring memory governance entirely to the operating system.

Boot Services Memory Reclamation

Memory used by Boot Services is marked under specific memory types in the UEFI memory map:

• EfiBootServicesCode: Holds the executable binaries of the UEFI drivers and applications running prior to OS handover.
• EfiBootServicesData: Contains the heap, stack, and data structures utilized by the Boot Services drivers.

Because these services are non-operational once the operating system kernel is active, this memory becomes obsolete. During the handover, the operating system inspects the memory map retrieved just prior to calling ExitBootServices(). Any ranges tagged as EfiBootServicesCode or EfiBootServicesData are marked as free physical pages by the operating system’s memory manager, allowing them to be reclaimed and allocated for user-space programs or kernel buffers.

Runtime Services Memory Preservation

Unlike Boot Services, Runtime Services are designed to persist indefinitely to provide essential low-level platform functionality to the running operating system, such as modifying NVRAM variables, reading the Real-Time Clock (RTC), and executing system resets.

The memory associated with these services is categorized as:

• EfiRuntimeServicesCode: Contains executable code for services the OS can call at runtime.
• EfiRuntimeServicesData: Stores the static and working data used by runtime code.

The operating system cannot reclaim these memory regions. Reusing this memory would corrupt the firmware code and lead to system crashes when the OS invokes runtime interfaces. Instead, the OS preserves these physical addresses. If operating in virtual memory mode, the OS typically invokes SetVirtualAddressMap() to map these runtime code and data regions into the kernel's virtual memory space, ensuring uninterrupted access to the firmware interfaces without interfering with OS address space layout.

Summary of Differences