UEFI

What It Is

UEFI (Unified Extensible Firmware Interface) is the firmware standard used by nearly all modern PCs, servers, and laptops. It replaced the older BIOS standard starting in the mid-2000s. UEFI initializes hardware, finds an operating system, and hands off control.

Strictly speaking, UEFI is not the first code that runs. On Intel systems, the Intel ME wakes up before the main CPU and handles early hardware initialization. On AMD, the AMD PSP does the same. These management processors release the main CPU from reset, and then UEFI's SEC phase begins. UEFI is the first code that runs on the main CPU -- the management processors are a layer below it (see 01 Power and Firmware for the full power-on sequence).

Think of it as the bootloader for the bootloader. Your OS has a bootloader (GRUB, systemd-boot, etc.), but UEFI is what runs before that bootloader.

UEFI is not a single program -- it's a specification (maintained by the UEFI Forum) that hardware vendors implement. Intel's implementation is called TianoCore (open source). Every major vendor (Dell, HP, Lenovo, etc.) ships firmware based on TianoCore or a commercial derivative (AMI, Insyde, Phoenix).

How It Works

Boot Phases

UEFI initializes in a strict sequence of phases. Each phase has more capabilities than the last because earlier phases set up the resources that later phases need.

SEC (Security Phase): The very first code to execute. Written in assembly, architecture-specific. Its only job is to set up temporary memory using CPU cache (a trick called "cache-as-RAM" or "no-eviction mode") and establish the initial root of trust. Without RAM, you can't run complex code -- SEC is the bootstrap that makes everything else possible.

PEI (Pre-EFI Initialization): Initializes real RAM (DRAM). This is the critical transition -- before PEI completes, only a few kilobytes of cache memory are available. PEI runs specialized modules (PEIMs) that detect the memory configuration and program the memory controller. Results are passed to the next phase via data structures called Hand-Off Blocks (HOBs).

DXE (Driver Execution Environment): The main initialization phase. Now that full RAM is available, DXE loads drivers for all hardware: USB controllers, storage (NVMe, SATA), GPU, network adapters. The DXE Dispatcher discovers and executes drivers in dependency order -- similar to how a package manager resolves dependencies. When DXE completes, all hardware is usable and the UEFI Boot Services and Runtime Services tables are available.

BDS (Boot Device Selection): The Boot Manager reads the boot variable list from NVRAM:

BootOrder -- an ordered list of entry numbers (e.g., 0001, 0003, 0002)
Boot0001 -- points to \EFI\ubuntu\shimx64.efi on partition with GUID X
Boot0003 -- points to \EFI\Microsoft\Boot\bootmgfw.efi on partition Y
And so on

The Boot Manager tries each entry in order. Each points to an EFI executable on an EFI System Partition (ESP). If all entries fail, firmware tries the removable media fallback path \EFI\BOOT\BOOTx64.EFI on any ESP.

TSL (Transient System Load): The OS-provided bootloader runs (still within the UEFI environment). Boot Services are still available -- the bootloader can allocate memory, access storage, and use UEFI protocols. The bootloader loads the OS kernel into memory and calls ExitBootServices(), which terminates this phase.

RT (Runtime): After ExitBootServices(), the OS owns the platform. Only UEFI Runtime Services remain: NVRAM variable access (for boot entries, Secure Boot keys), the real-time clock, and the capsule update mechanism. The firmware is mostly dormant.

The EFI System Partition (ESP)

The ESP is a small FAT32 partition (typically 100-550 MB) with a specific GPT partition type GUID. Every UEFI system has one. It's where bootloaders live -- each OS installs its bootloader into a subdirectory:

ESP/
  EFI/
    BOOT/
      BOOTx64.EFI          # Fallback for removable media
    ubuntu/
      shimx64.efi          # Ubuntu's bootloader
      grubx64.efi
    Microsoft/
      Boot/
        bootmgfw.efi       # Windows Boot Manager
    FortrOS/
      preboot.efi          # FortrOS preboot UKI

The ESP uses FAT32 because every UEFI implementation is required to support it -- no OS-specific filesystem drivers needed.

NVRAM Variables

UEFI stores configuration in NVRAM (non-volatile RAM on the motherboard, typically part of the SPI flash chip). Boot entries, Secure Boot keys, and hardware settings live here. The OS can read and write these variables via Runtime Services -- this is how efibootmgr on Linux or bcdedit on Windows modifies boot entries.

Security Considerations

Firmware is Ring -2. If firmware is compromised, everything above it is compromised. The OS, the hypervisor, the TPM -- all depend on firmware integrity. A firmware rootkit persists across OS reinstalls and disk wipes because the firmware isn't on the disk.

Vendor update cadence varies wildly. Some vendors ship firmware updates for years; others abandon hardware within months. Unpatched firmware vulnerabilities (LogoFAIL, PixieFail, BlackLotus) have demonstrated real-world firmware exploitation.

The UEFI attack surface is large. DXE drivers, option ROMs from add-in cards, network boot stacks -- all run at firmware privilege. Secure Boot helps by verifying signatures, but it only covers the boot path, not the firmware's own initialization.

UEFI Setup is an attack surface. An attacker with physical access (or a BIOS vulnerability) can enter UEFI Setup and: add boot entries pointing to a malicious OS, disable Secure Boot, change the boot order, or modify NVRAM variables. Vendor BIOS passwords provide some protection but are notoriously bypassable on some hardware (Dell, for example, has had multiple password bypass vulnerabilities). UEFI Setup lockdown is a defense-in-depth measure, not a guarantee.

How FortrOS Uses It

FortrOS relies on UEFI as the firmware layer on all hardware:

ESP stores the preboot UKI -- a single signed binary containing the preboot kernel, initramfs, and command line
Secure Boot verifies the UKI signature against the org's CA certificate enrolled in the firmware's db
NVRAM variables store the boot entry pointing to the FortrOS UKI, plus cached state (gateway IP, generation ID) that survives reboots
Runtime Services provide NVRAM access to the running OS for reading and updating these variables

FortrOS does not modify or replace the UEFI firmware itself. It works with whatever firmware the vendor ships. But FortrOS takes positive control of the UEFI configuration during provisioning:

Remove other boot entries: Delete NVRAM entries for other operating systems. Only the FortrOS preboot UKI should be bootable.
Set UEFI admin password: Prevent physical attackers from entering UEFI Setup to disable Secure Boot or add malicious boot entries. The password is org-managed (stored in org state, rotatable).
Disable unnecessary boot paths: Turn off USB boot, network boot (after provisioning), and CSM (legacy BIOS compatibility). Reduce the attack surface to: local ESP with Secure Boot only.
Lock Secure Boot keys: Enroll the org's CA and remove Setup Mode access. Prevents key database modification without the org's KEK.

The level of lockdown is org-policy-driven. A homelab may skip UEFI password and keep USB boot enabled for convenience. A government deployment locks everything and treats UEFI Setup access as a security incident. The provisioner applies the org's firmware policy during enrollment using UEFI Runtime Services and efibootmgr.

Alternatives

BIOS (legacy): The predecessor to UEFI. 16-bit real mode, 1MB address limit, no Secure Boot, no GPT, limited to MBR partitioning. Still works on old hardware but no modern OS targets it as primary. UEFI provides "CSM" (Compatibility Support Module) to emulate BIOS for legacy OS support -- FortrOS does not use CSM.

coreboot: Open-source firmware that replaces the vendor UEFI entirely. Used by ChromeOS, System76, and some server vendors. Gives full control over the firmware, including the ability to neutralize Intel ME. The tradeoff is narrow hardware support -- only boards with coreboot ports are supported. See 01 Power and Firmware for how FortrOS handles coreboot as an additive option.

LinuxBoot: Replaces the DXE and BDS phases of UEFI with a Linux kernel. PEI still runs (for RAM init), but once RAM is available, a Linux kernel takes over as the firmware's "application layer." Used by some hyperscaler server vendors (Google, Facebook). More flexible than UEFI but requires firmware-level integration.