Preserving UEFI Variables in VM Snapshots and Migration

Unified Extensible Firmware Interface (UEFI) runtime variables store critical configuration and security metadata, such as Secure Boot keys, boot order, and operating system crash logs. In virtual environments, these variables must remain consistent across state-altering operations. Virtualization platforms and snapshot tools preserve UEFI runtime variables by synchronizing the hypervisor's emulated Non-Volatile RAM (NVRAM) storage files with active system memory states during live migrations and snapshot creation.

The Architecture of Virtual UEFI Variables

Unlike legacy BIOS, UEFI maintains state that persists across system reboots and can be modified while the operating system is actively running via UEFI Runtime Services (such as GetVariable and SetVariable). In a virtual machine (VM), these variables do not write to physical motherboard flash chips. Instead, the hypervisor emulates non-volatile storage using dedicated virtual flash images (such as OVMF/EDK2 NVRAM files in QEMU/KVM, .nvram files in VMware ESXi, or VHDX-embedded state in Hyper-V).

Because modern operating systems cache these variables in physical memory (RAM) and flush updates to emulated flash asynchronously, maintaining variable consistency requires treating both the disk-backed NVRAM and the guest memory as interdependent states.

How Snapshot Tools Preserve UEFI State

Snapshots capture a point-in-time state of a virtual machine. The approach taken depends on whether the snapshot includes running memory:

  • Crash-Consistent (Disk-Only) Snapshots: The hypervisor creates a copy-on-write (CoW) layer for both the VM’s virtual disks and its NVRAM file. If changes are written to the UEFI variables after the snapshot is taken, the updates route to the delta/redo log, leaving the original NVRAM state intact. However, because memory is discarded, any variable updates sitting purely in OS buffers or uncommitted hardware caches at the moment of capture are lost, mimicking a sudden power loss.
  • Live (Memory-Included) Snapshots: The hypervisor pauses guest vCPU execution and generates a simultaneous dump of the guest RAM, CPU registers, and the emulated flash device state. By checkpointing the memory contents alongside the NVRAM file, the snapshot ensures that the OS-level memory pointers to runtime services match the exact state of the underlying NVRAM device. When reverting, the hypervisor restores both files concurrently, preventing desynchronization between OS-cached variables and firmware tables.

How Live Migration Tools Preserve UEFI State

During live migration (such as VMware vMotion or QEMU Pre-Copy Live Migration), the goal is to transfer the VM between distinct physical hosts with zero observable downtime. Preserving UEFI runtime variables involves coordinated device state serialization:

  1. NVRAM Device Serialization: Hypervisors use internal device models (such as QEMU’s vmstate subsystem or ESXi's VMX device tracking) to serialize the register states, buffers, and active read/write commands of the emulated parallel flash (pflash) device.
  2. Iterative Memory Transfer: While the VM continues running on the source host, dirty memory pages are iteratively copied to the destination host. Since the guest kernel’s UEFI runtime variable cache resides in RAM, it transfers naturally via the iterative memory copy loop.
  3. Storage Hand-off:
    • In shared-storage architectures, the NVRAM file remains on a shared cluster file system (e.g., VMFS, NFS, or Ceph). During the final switchover phase (the "stun" period), the source host relinquishes the lock on the NVRAM file, and the destination host assumes read/write ownership.
    • In shared-nothing (storage migration) scenarios, the hypervisor mirror-writes NVRAM blocks over the network alongside virtual disk blocks, finalizing the transfer before switching vCPU execution.
  4. Final Synchronization: During the brief pause when vCPUs are switched to the destination node, any final uncommitted variable writes held in emulated hardware queues are flushed to the NVRAM file, ensuring the destination host boots the vCPUs with completely synchronized NVRAM and memory.

Security Implications: Rollback Prevention and Secure Boot

UEFI runtime variable preservation is crucial for maintaining platform security. If an attacker could trigger a rollback of only the NVRAM file while running newer software, they could potentially revert Secure Boot signature databases (db, dbx) to bypass blacklisted bootloader restrictions.

Hypervisors prevent this vulnerability by strictly binding NVRAM configurations to parent disk chains and VM descriptors. Any operation that reverts disks or memory automatically forces the NVRAM device to revert to the matching cryptographic and configuration state, maintaining the chain of trust established at the VM's creation.