Skip to content

SYSTEM Cited by 1 source

UEFI (Unified Extensible Firmware Interface)

Definition

UEFI (Wikipedia) is the modern firmware standard that initialises hardware after power on and hands off control to the operating system. Successor to the legacy BIOS; now the default firmware on essentially all modern x86 and ARM server + client hardware. UEFI runs a Power-On Self-Test (POST), brings up peripherals, and then enters a pre-boot environment in which boot loaders execute (PXE / iPXE / GRUB / Windows Boot Manager).

UEFI is also a configuration surface — boot order, secure boot keys, network-boot interface preferences, hardware tunables — exposed through a forms-rendering subsystem (HII, the Human Interface Infrastructure) that vendors customise per platform.

Network boot path on UEFI

UEFI supports two primary network-boot interfaces (per the 2026-06-01 Cloudflare Gen12 boot post):

  • Preboot Execution Environment (PXE) — the legacy network-boot protocol; used in conjunction with iPXE open-source firmware to support modern HTTP/HTTPS protocols.
  • UEFI HTTPS boot — a native UEFI capability where "the computer's motherboard firmware [downloads] operating system files securely" over HTTPS without requiring iPXE chainloading.

In production, a server typically has multiple variants configured (IPv4 HTTPS, IPv4 PXE-over-iPXE, IPv6 HTTPS, IPv6 PXE-over-iPXE), and the firmware probes them in order until one succeeds. The probe order matters operationally: each unreachable interface burns "roughly five minutes" on a timeout before falling through.

Configuration as data structures (HII / IFR)

UEFI configuration is stored in HII forms described by IFR (Internal Forms Representation) opcodes. The Cloudflare 2026-06-01 post discloses one specific opcode shape:

typedef struct _EFI_IFR_REF3 {
  EFI_IFR_OP_HEADER          Header;
  EFI_IFR_QUESTION_HEADER    Question;
  EFI_QUESTION_ID            QuestionId;
  EFI_GUID                   FormSetId;
} EFI_IFR_REF3;

The relevance: HII data structures are commonly lazy-loaded — "data is not instantiated until it is explicitly accessed via a GUI callback. While this is standard industry practice to accelerate BIOS boot times, it rendered the 'Network Boot Interface' invisible to programmatic scans. Because the structure hadn't been 'loaded' yet, our automation couldn't discover the priorities." This is the load-bearing failure mode for any fleet automation that wants to read or modify network-boot configuration without going through the BIOS GUI.

Why fleet automation finds UEFI hard

Three structural properties (per the Cloudflare 2026-06-01 disclosure):

  1. Configuration persistence is not guaranteed across firmware upgrades. "Configuration settings are often reset following a UEFI firmware upgrade." Any automation must validate state post-upgrade and re-apply.
  2. Older UEFI versions don't support boot ordering. Any fleet-scale boot-order discipline must coexist with un- orderable hardware — and the automation layer (e.g. iPXE) must mediate.
  3. OEM-locked settings. Some settings are immutable by default — Cloudflare encountered a Force Priority Httpv4 Httpv6 Pxev4 Pxev6 token that "was preventing us from changing the boot order" and required "a new BIOS version from our vendor and a debug session" to unblock. Vendors sometimes maintain a "Boot Order Module" with specific tokens that must be enabled to allow programmatic discovery without GUI interaction.

Seen in

2026-06-01 — Cloudflare Gen12 fleet boot-time regression

Source: sources/2026-06-01-cloudflare-how-we-reduced-core-unit-boot-time-from-hours-to-minutes.

Canonical wiki disclosure of UEFI as a fleet-automation substrate. UEFI's three-stage handoff (firmware initialisation → pre-boot PXE → kernel startup) is what Cloudflare's boot automation operates on; the bug being fixed is structurally an absence of declared boot order in UEFI's network-boot interface list, surfaced when a firmware update changed which interface won the linear-search race. Cloudflare's response:

  • Declare boot interface order upfront in the pre-boot PXE stage.
  • State validation with auto-reapply to handle persistence loss across firmware upgrades.
  • Vendor coordination to unlock the immutable Force Priority Httpv4 Httpv6 Pxev4 Pxev6 setting and to force discovery of the lazy-loaded EFI_IFR_REF3 "Network Boot Interface" structure during the boot sequence (not via GUI callback).

Headline fleet outcome: firmware-upgrade automation 4 hours → 3 minutes; subsequent single-boot 20 minutes → < 1 minute, on the Gen12 fleet of ~2,000 core servers.

Trade-offs vs legacy BIOS

Property BIOS UEFI
Boot mode MBR GPT, larger disk support
Boot loader API INT 13h conventions EFI applications
Network boot PXE (TFTP) PXE + HTTPS native
Configuration NVRAM key/value Structured HII forms (IFR)
Programmability Limited Pre-boot apps + scripts
Secure boot Optional bolt-on First-class
Fleet automation Per-OEM API Common HII surface (in theory)

The "in theory" caveat is what Cloudflare's 2026-06-01 post documents: vendor-specific quirks (lazy-loaded structures, immutable tokens, NIC string drift) prevent the in-principle common HII surface from delivering uniform fleet automation in practice.

Last updated · 542 distilled / 1,571 read