How UEFI Non-Volatile Variables Store System Settings

Unified Extensible Firmware Interface (UEFI) non-volatile variables provide a standardized, persistent mechanism for the system firmware and operating systems to read, write, and maintain configuration data across reboots and power outages. By storing structured key-value data directly in non-volatile memory—most commonly the motherboard's Serial Peripheral Interface (SPI) flash chip—UEFI ensures that critical settings, such as boot paths, hardware initialization profiles, and cryptographic keys, remain intact. This article explains how these variables are structured, accessed, and secured to govern modern system behavior.

Architecture and Data Structure

A UEFI variable is identified not by a simple string alone, but by a combination of a globally unique identifier (GUID) and a null-terminated Unicode string name. This combination prevents naming collisions between standard specifications, hardware original equipment manufacturers (OEMs), and operating system vendors.

Each variable consists of four main components:

  • Vendor GUID: A 128-bit identifier defining the namespace of the variable (e.g., the global UEFI namespace or an OEM-specific namespace).
  • Variable Name: A human-readable identifier specifying the setting, such as BootOrder or SecureBoot.
  • Attributes: A bitmask defining how and when the variable can be accessed and whether it persists across power cycles.
  • Data Payload: The binary data or structured payload representing the actual configuration state.

The Storage Medium

UEFI non-volatile variables reside in a dedicated section of Non-Volatile Random-Access Memory (NVRAM), typically carved out of the motherboard's SPI NOR flash memory alongside the firmware binary. Because NOR flash has finite write/erase cycles and must be erased in blocks, the firmware incorporates wear-leveling algorithms and garbage-collection routines to manage space efficiently and avoid premature hardware degradation.

Access via UEFI Runtime Services

The UEFI specification provides an abstraction layer known as Runtime Services, allowing both pre-boot firmware drivers and operating system kernels to interact with variables. The two primary API calls governing this behavior are:

  • GetVariable(): Retrieves the variable's payload, size, and access attributes using its name and GUID.
  • SetVariable(): Writes, updates, or deletes a variable. Passing a data size of zero to this function deletes the variable from NVRAM.

Operating systems interface with these Runtime Services directly. In Linux, these interfaces are exposed through the efivarfs pseudo-filesystem (/sys/firmware/efi/efivars/), whereas Windows manages them via the Win32 APIs GetFirmwareEnvironmentVariable and SetFirmwareEnvironmentVariable.

Attributes Governing Variable Lifecycles

The behavior of each variable is dictated by specific bitmask attributes assigned upon creation:

  • EFI_VARIABLE_NON_VOLATILE (NV): Instructs the system to preserve the variable in persistent storage. Without this flag, the variable is volatile and cleared upon reset.
  • EFI_VARIABLE_BOOTSERVICE_ACCESS (BS): Makes the variable accessible during the pre-boot phase before the OS loader calls ExitBootServices().
  • EFI_VARIABLE_RUNTIME_ACCESS (RT): Extends accessibility into the operating system environment after the kernel has booted.
  • EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS: Enforces cryptographic signature verification before allowing modifications, preventing unauthorized tampering.

Critical System Roles

Non-volatile variables handle several essential system functions:

  • Boot Target Management: Variables such as BootOrder (defining sequence) and Boot#### (defining distinct boot options containing device paths and partition UUIDs) instruct the system on which drive and EFI executable to load.
  • Platform Security: Secure Boot depends entirely on authenticated non-volatile variables to store the platform key (PK), key exchange keys (KEK), the authorized signature database (db), and the forbidden signature database (dbx).
  • OS-to-Firmware Handshakes: Operating systems write to specific variables to schedule diagnostic tests, initiate firmware capsule updates, or instruct the motherboard to reboot straight into the UEFI setup utility.