How UEFI Variable Attributes Govern Persistence

UEFI variables store system configuration and state data across different phases of system initialization and operating system operation. This article explains how specific variable attributes—primarily EFI_VARIABLE_BOOTSERVICE_ACCESS, EFI_VARIABLE_RUNTIME_ACCESS, and EFI_VARIABLE_NON_VOLATILE—define the lifecycle, accessibility windows, and persistence of data across system boots and runtime execution.

The Role of UEFI Variable Attributes

When a UEFI variable is created using the SetVariable() interface, it is assigned a 32-bit bitmask of attributes. These attributes explicitly dictate where the variable resides, how long it survives, and which execution phases can read or modify it.

Persistence and access are governed by three primary flags:

  • EFI_VARIABLE_NON_VOLATILE (NV)
  • EFI_VARIABLE_BOOTSERVICE_ACCESS (BS)
  • EFI_VARIABLE_RUNTIME_ACCESS (RT)

While persistence across power cycles strictly depends on non-volatile storage, access permissions dictate whether the data can actually be read, altered, or preserved across execution boundaries.

Understanding the Attributes

EFI_VARIABLE_NON_VOLATILE (NV)

The NV attribute directly controls hardware persistence.

  • Present: The variable is committed to persistent storage, typically the SPI flash chip alongside the firmware. It survives power loss, system reboots, and firmware updates unless explicitly deleted.
  • Absent: The variable is volatile and resides entirely in system RAM. It is lost immediately upon a power cycle or platform reset.

EFI_VARIABLE_BOOTSERVICE_ACCESS (BS)

The BS attribute defines variable visibility during the pre-boot phase.

  • It grants access to the variable while UEFI Boot Services are active.
  • These services are available to UEFI drivers, the Driver Execution Environment (DXE), Boot Device Selection (BDS), and OS bootloaders up until the operating system takes control.

EFI_VARIABLE_RUNTIME_ACCESS (RT)

The RT attribute defines variable visibility after Boot Services have terminated.

  • Once an operating system bootloader calls ExitBootServices(), Boot Services code and data are discarded or reclaimed by the OS.
  • Variables with the RT flag remain mapped into memory and accessible to the operating system kernel via UEFI Runtime Services (such as /sys/firmware/efi/efivars in Linux or GetFirmwareEnvironmentVariable in Windows).

Attribute Dependency Rules

The UEFI Specification defines strict rules governing how these flags can be combined:

  1. Runtime Access Requires Boot Service Access: An attribute combination of RT without BS is invalid. A variable cannot be exposed to the OS at runtime if it was not also exposed during boot services. If a caller passes RT without BS to SetVariable(), the firmware rejects the operation with EFI_INVALID_PARAMETER.
  2. Access Windows vs. Storage Media: BS and RT do not determine whether a variable survives a reboot; they only dictate the time frame during which the variable's interface can be called. However, to persist a change made from the running OS, the variable must include both NV and RT (and consequently BS).

Common Attribute Combinations and Persistence Behaviors

1. Boot Service Only (BS)

  • Persistence: Volatile (lost on reboot).
  • Access Window: Available strictly before ExitBootServices().
  • Use Case: Passing temporary parameters between DXE drivers or conveying initialization state between the firmware and the OS bootloader.

2. Boot Service + Non-Volatile (BS | NV)

  • Persistence: Non-volatile (persists across reboots in SPI flash).
  • Access Window: Pre-boot only. It becomes completely invisible once the OS kernel initializes.
  • Use Case: Internal firmware settings, hardware initialization profiles, and secure parameters that the OS should neither read nor tamper with directly.

3. Boot Service + Runtime Access (BS | RT)

  • Persistence: Volatile (lost on reboot).
  • Access Window: Accessible during pre-boot and throughout the OS runtime.
  • Use Case: Ephemeral runtime coordination between the OS and firmware, such as diagnostic logs or dynamic memory allocation tables that do not need to survive a power cycle.

4. Boot Service + Runtime Access + Non-Volatile (BS | RT | NV)

  • Persistence: Non-volatile (persists across reboots in SPI flash).
  • Access Window: Permanently available in both pre-boot and runtime environments.
  • Use Case: Global system settings configured by the OS or user, including BootOrder, BootNext, Secure Boot keys (PK, KEK, db), and platform setup options.