How UEFI Manages Error Logs and Telemetry Storage

Unified Extensible Firmware Interface (UEFI) systems rely on dedicated non-volatile storage mechanisms, hardware abstraction tables, and platform standards to record diagnostic data across system reboots. This article examines how UEFI firmware allocates non-volatile memory, utilizes ACPI Platform Error Interfaces (APEI) such as the Error Record Serialization Table (ERST), manages Common Platform Error Records (CPER), and coordinates with operating systems to preserve critical hardware failures and runtime telemetry without relying on traditional storage drives.

Non-Volatile RAM (NVRAM) and SPI Flash

At the core of UEFI persistence is the SPI NOR flash chip soldered to the motherboard. UEFI manages a portion of this flash memory as Non-Volatile Random-Access Memory (NVRAM) to store persistent variables alongside the firmware image itself.

When firmware or an operating system needs to persist diagnostic markers, it uses the UEFI Runtime Services API—specifically SetVariable(). To ensure the data survives power loss and system resets, the variable is defined with the attribute EFI_VARIABLE_NON_VOLATILE.

Because SPI NOR flash has limited write endurance and constrained capacity (typically 16MB to 64MB shared with the firmware code), UEFI implementations employ strict space management strategies:

  • Garbage Collection and Wear Leveling: Firmware tracks valid, deleted, and stale variable entries, reclaiming blocks when space runs low.
  • Variable Size Limits: Individual telemetry or log variables are typically capped (often between 4KB and 64KB) to prevent rogue logs from exhausting firmware storage.

ACPI Platform Error Interfaces (APEI)

For hardware faults and fatal system crashes, writing directly via standard UEFI variables during an unrecoverable failure is often too slow or unsafe. Modern systems use the ACPI Platform Error Interfaces (APEI) framework, which defines standardized hardware-to-software communication for telemetry and error reporting.

Key APEI tables that interface with persistent storage include:

  • Hardware Error Source Table (HEST): Identifies all platform hardware error sources (such as PCIe Advanced Error Reporting, memory controller errors, and processor machine checks) and the signaling mechanisms used.
  • Boot Error Record Table (BERT): Reserves persistent memory to communicate unhandled errors that caused a reset or crash during the previous boot cycle. Firmware writes the fatal error to a designated physical memory location or non-volatile block before resetting, and populates the BERT table for the OS to parse during the subsequent initialization.
  • Error Record Serialization Table (ERST): Acts as the hardware abstraction interface for reading and writing error records to a persistent storage location (often dedicated non-volatile memory or reserved NVRAM sectors). ERST defines an instruction set (such as read, write, and clear operations) that firmware or an OS can execute to manage persistent records without needing direct hardware-specific flash controllers.

Common Platform Error Record (CPER) Format

Data written to persistent storage via APEI is structured according to the UEFI Common Platform Error Record (CPER) specification. Standardized under the UEFI Specification (Appendix N), CPER formats telemetry data into machine-readable headers and descriptors.

A CPER record contains:

  • Record Header: Includes error severity (correctable, recoverable, or fatal), timestamp, platform ID, and record length.
  • Section Descriptors: Defines the type of hardware subsystem affected (such as Processor, Memory, PCIe, or Firmware).
  • Section Body: Contains granular architecture-specific register dumps, physical hardware addresses, and localized diagnostic data.

By storing telemetry in the CPER format, different operating systems (such as Windows via the Windows Hardware Error Architecture [WHEA] or Linux via the kernel's EDAC and APEI drivers) can consistently parse errors generated by the firmware.

Operating System Integration and Crash Logging

The operating system uses UEFI and APEI interfaces to persist crash telemetry directly to firmware storage when the main storage subsystem (SATA, NVMe) is inaccessible or compromised.

Linux pstore and efi-pstore

Linux implements the Persistent Storage (pstore) filesystem, with the efi-pstore backend mapping directly to UEFI NVRAM. When a kernel panic occurs, the OS writes the panic log, console dmesg buffer, and MCE (Machine Check Exception) records to UEFI variables named with a specific prefix (e.g., dump-type-*). On reboot, the system mounts /sys/fs/pstore to expose the saved logs as standard files, allowing administrators to inspect fatal crashes that prevented disk writes.

Windows Hardware Error Architecture (WHEA)

Windows leverages WHEA to read APEI tables upon boot. Fatal errors recorded in persistent storage via the ERST or BERT are processed by WHEA, mapped into Windows Event Tracing (ETW), and written to the System Event Log for post-crash analysis.

Enterprise Telemetry and BMC Offloading

In enterprise and server hardware, the primary UEFI SPI flash is often complemented or bypassed for telemetry to avoid flash exhaustion:

  • Baseboard Management Controllers (BMC): Server platforms route UEFI-level telemetry, POST codes, and hardware alerts to a dedicated out-of-band processor (BMC) via interfaces such as IPMI or Redfish.
  • System Event Log (SEL): Rather than storing large telemetry streams on the UEFI SPI chip, firmware sends CPER payloads directly to the BMC's dedicated eMMC or flash storage, preserving motherboard SPI endurance while enabling remote management independent of host OS state.