What Are Global UEFI Variables and What Do They Store?

Unified Extensible Firmware Interface (UEFI) global variables are standardized, non-volatile data structures that enable seamless communication between system firmware and the operating system. Defined by the official UEFI specification, these variables reside in non-volatile memory (NVRAM) and persist across system reboots and power cycles. This article explains the technical definition of global UEFI variables and details the critical boot configurations, security keys, and hardware states they typically store.

Defining Global UEFI Variables

Global UEFI variables are distinguished by a standardized globally unique identifier (GUID) defined in the UEFI Specification: the EFI_GLOBAL_VARIABLE vendor GUID (8BE4DF61-93CA-11D2-AA0D-00E098032B8C). While hardware vendors can define proprietary variables using their own GUIDs, global variables follow a universal naming convention and structure that any UEFI-compliant operating system or bootloader can access and interpret.

These variables are managed by UEFI Runtime Services using standard API functions such as GetVariable and SetVariable. They possess specific attributes that determine their access levels, such as whether they are accessible only during the boot phase (Boot Services) or continue to be accessible after the operating system loads (Runtime Services), and whether they are read-only or read/write.

Key Categories of Data Stored in Global UEFI Variables

Global UEFI variables store several categories of low-level configuration and operational data required for platform initialization:

1. Boot Configuration and Management

The primary function of global UEFI variables is to control how the system initializes and selects an operating system. Key variables include:

  • BootOrder: An ordered array of 16-bit integers specifying the priority order in which firmware attempts to execute available boot options.
  • Boot#### (e.g., Boot0001, Boot0002): Individual configuration profiles containing the display label, device path, and optional command-line arguments needed to locate and execute an OS bootloader like GRUB or the Windows Boot Manager.
  • BootNext: A single boot option index that forces the system to boot into a specific option on the next restart only, reverting to BootOrder afterward.
  • BootCurrent: A read-only value indicating which Boot#### entry the firmware launched during the active session.

2. System and Hardware Console Configuration

Variables in this category define the paths and mechanisms used for early system input and output:

  • ConIn, ConOut, and ErrOut: Device paths pointing to the active input device (such as a keyboard), standard display console, and standard error stream during the pre-boot phase.
  • Timeout: The duration (in seconds) the firmware waits for user interaction before proceeding to load the first entry in BootOrder.

3. Platform Localization

To ensure interface consistency across the pre-boot environment, firmware stores localization settings as global variables:

  • PlatformLang: The current language code the platform uses (such as en-US).
  • PlatformLangCodes: A read-only list of RFC 4646 language codes supported by the platform's firmware.

4. OS-to-Firmware Signaling

Global variables allow the running operating system to request actions from the firmware upon the subsequent reboot:

  • OsIndications: A bitmask written by the operating system to request actions such as entering the UEFI setup utility, initiating capsule firmware updates, or resetting platform hierarchy keys.
  • OsIndicationsSupported: A read-only bitmask provided by the firmware indicating which OS-requested actions it supports.

5. Security and State Data

While cryptographic databases typically reside under dedicated security GUIDs, the state of platform security mechanisms is exposed via global variables:

  • SecureBoot: A read-only flag indicating whether UEFI Secure Boot verification is currently active (value 1) or inactive (value 0).
  • SetupMode: Indicates whether the platform is in user mode (enforcing Secure Boot policy) or setup mode (allowing platform keys to be provisioned without authentication).