UEFI Memory Types and OS Physical RAM Mapping

When a modern system boots, the Unified Extensible Firmware Interface (UEFI) constructs a detailed memory map that profiles every physical address range across the platform's hardware. This article examines how operating systems ingest UEFI memory descriptors, interpret specific memory types and cacheability attributes, and apply those definitions to configure architectural page tables, memory caching behaviors, and runtime access protections across physical RAM.

The UEFI Memory Map Structure

During the pre-boot environment, the operating system's bootloader invokes the UEFI boot service GetMemoryMap(). This function returns an array of EFI_MEMORY_DESCRIPTOR structures. Each descriptor defines:

  • Type: An enumeration (EFI_MEMORY_TYPE) describing the intended role of the memory range.
  • PhysicalStart: The base physical address of the range.
  • VirtualStart: The virtual address reserved for runtime services (if mapped).
  • NumberOfPages: The size of the region measured in 4 KiB pages.
  • Attribute: Bitmask flags specifying hardware capabilities such as cacheability, write protection, and execution privileges.

Operating systems parse these descriptors to differentiate between general-purpose memory, hardware-mapped I/O, and regions reserved strictly for firmware execution.

Memory Types and OS Allocation Strategies

The EFI_MEMORY_TYPE field dictates how the operating system treats each region of physical memory once it assumes control of the hardware:

Reclaimable Memory

  • EfiConventionalMemory: Free physical RAM with no firmware dependencies. The operating system places this memory directly into its free page pools for general allocation to kernel and user space.
  • EfiBootServicesCode and EfiBootServicesData: Memory used by UEFI drivers and applications during the boot sequence. Once the operating system issues the ExitBootServices() call, these regions are no longer needed by firmware, allowing the OS memory manager to reclaim the underlying physical frames as standard RAM.
  • EfiLoaderCode and EfiLoaderData: Memory allocated by the OS loader. The kernel reclaims this memory once initialization completes.

Preserved and Firmware-Reserved Memory

  • EfiRuntimeServicesCode and EfiRuntimeServicesData: Regions containing firmware code and data structures that the operating system must execute while running (for example, to update UEFI NVRAM variables or set system wake timers). The OS must map these regions into its virtual address space—often preserving identity mapping or applying page mappings specified by SetVirtualAddressMap().
  • EfiACPIReclaimMemory: Contains Advanced Configuration and Power Interface (ACPI) tables. The OS can reclaim this space only after reading and copying the ACPI tables into internal structures.
  • EfiACPIMemoryNVS: Non-Volatile Sleep memory used by firmware. The operating system must never overwrite or reclaim this memory; it must remain intact across low-power system sleep states.
  • EfiReservedMemoryType: Ranges reserved by hardware or firmware implementations that the OS must leave untouched.

Device and I/O Space

  • EfiMemoryMappedIO and EfiMemoryMappedIOPortSpace: Physical address ranges assigned to peripheral device registers rather than real RAM. The OS maps these regions without caching to allow memory-mapped device communication.

Translating Cache Attributes to Page Table Flags

The Attribute field within EFI_MEMORY_DESCRIPTOR informs the OS of the platform-supported cache attributes for each memory range. The OS translates these flags into CPU-specific page table entry (PTE) bits and memory type registers:

  • EFI_MEMORY_UC (Uncacheable): Informs the OS that accesses to this memory must not be cached by the CPU. The OS sets the PTE caching bits accordingly (such as configuring Page Attribute Tables (PAT) or MTRRs on x86, or MAIR Device/Non-Cacheable attributes on ARM). This is standard for MMIO regions.
  • EFI_MEMORY_WC (Write-Combining): Allows loose write ordering and combines multiple writes into single transactions. The OS applies this primarily to video framebuffers.
  • EFI_MEMORY_WT (Write-Through) and EFI_MEMORY_WB (Write-Back): Dictate standard caching behaviors. For general RAM (EfiConventionalMemory), the OS applies EFI_MEMORY_WB to maximize performance by utilizing L1–L3 processor caches.

The operating system enforces the strictest supported cacheability attribute to avoid cache-coherency hazards, ensuring it does not map an uncacheable hardware range as write-back RAM.

Security and Protection Attributes

Modern UEFI specifications (UEFI 2.5+) provide fine-grained execution and access attributes to harden the firmware-to-OS interface:

  • EFI_MEMORY_RO (Read-Only): The OS maps the target physical range with read-only permissions in its page tables, preventing modification of static firmware data or code.
  • EFI_MEMORY_XP (Execute-Protect): Dictates that the OS must set the No-Execute (NX) or Execute-Disable (XD) bit on the corresponding page table entries. Data regions—such as EfiRuntimeServicesData—are mapped with the execute-disable bit set to mitigate memory corruption vulnerabilities within firmware.

By adhering strictly to the memory types and attribute flags supplied by UEFI, the operating system ensures that general RAM is fully harvested, critical firmware services remain functional, hardware registers remain uncorrupted by CPU caches, and platform security boundaries are maintained from initial boot through active runtime.