UEFI Variables and Kernel Command-Line Arguments

UEFI environment variables serve as a foundational mechanism for defining, storing, and passing kernel command-line arguments during the system boot process. Stored in non-volatile RAM (NVRAM), these variables allow the UEFI Boot Manager and intermediate bootloaders to supply configuration parameters directly to an operating system kernel. This article examines how UEFI variables encapsulate boot options, how the UEFI architecture delivers these parameters to the kernel, and the operational advantages this integration provides for modern system management.

The Role of Boot#### and EFI_LOAD_OPTION

At the firmware level, UEFI manages boot targets using variables named Boot#### (where #### is a four-digit hexadecimal number) referenced by the BootOrder variable. Each Boot#### variable stores a standardized binary structure known as EFI_LOAD_OPTION.

The EFI_LOAD_OPTION structure consists of:

  • Attributes: Flags defining whether the entry is active or hidden.
  • FilePathList: The device path to the target EFI binary (such as a bootloader or a kernel with an embedded EFI stub).
  • Description: A human-readable label for the boot option.
  • OptionalData: A binary or string payload placed at the end of the structure.

Kernel command-line arguments are stored inside this OptionalData field. When the UEFI firmware loads a binary, it populates an instance of the EFI_LOADED_IMAGE_PROTOCOL interface in memory. The data located in OptionalData is copied to the LoadOptions pointer of this protocol, while LoadOptionsSize tracks the length of the string.

Direct Kernel Execution via the EFI Boot Stub

Modern operating system kernels, including Linux compiled with CONFIG_EFI_STUB, can act as standalone EFI applications. When using the EFI stub:

  1. The UEFI Boot Manager reads the selected Boot#### variable from NVRAM.
  2. The firmware initializes the kernel image into memory and exposes the EFI_LOADED_IMAGE_PROTOCOL.
  3. The kernel's early EFI entry point accesses LoadOptions directly through the protocol.
  4. The kernel decodes this payload (typically an ASCII or UTF-16 string) into standard kernel boot parameters (such as root=UUID=..., ro, and quiet) before exiting UEFI boot services and transitioning into runtime mode.

This method eliminates the need for a secondary bootloader like GRUB, allowing the firmware to directly initialize the operating system using arguments held entirely within NVRAM.

Interaction with Intermediate Bootloaders

When an intermediate bootloader (such as GRUB, rEFInd, or systemd-boot) is used, UEFI variables still govern parameter handling, either directly or indirectly:

  • Receiving Arguments: The intermediate bootloader receives the initial command line via LoadOptions from the firmware. It can use these options to select a configuration profile, alter boot behavior, or append parameters.
  • Stateful Communication: Bootloaders frequently write to custom or standardized UEFI variables (such as LoaderCommandLine or LoaderEntrySelected) to communicate state to the OS or preserve configuration across reboots.
  • Overriding Defaults: Administrators can pass fallback flags to the bootloader itself through firmware NVRAM variables without mounting or editing storage filesystems.

Runtime Configuration and Security Considerations

Because UEFI variables are exposed to the operating system through UEFI Runtime Services, administrators can read and modify kernel arguments directly from user space using utilities like efibootmgr. Updating a kernel command line requires updating the OptionalData payload inside the relevant Boot#### variable, without altering the disk's partition table or master boot record.

Under UEFI Secure Boot, this capability introduces security trade-offs. If a user-space process with elevated privileges can alter Boot#### variables, it could potentially inject malicious command-line parameters (such as init=/bin/sh or parameters disabling security modules). To mitigate this:

  • Unified Kernel Images (UKIs): Modern Linux implementations often combine the kernel, initramfs, and a static, signed command line into a single cryptographic binary. In a UKI setup, the kernel ignores external LoadOptions passed by the NVRAM variable unless explicitly permitted, preventing unauthorized parameter tampering.
  • Firmware Protections: Firmware implementations can restrict variable write access to authenticated updates or apply policy checks before honoring runtime-modified parameters.