What Is the Firmware Interface Table in UEFI Updates?

The Firmware Interface Table (FIT) is an architectural data structure embedded within the system flash memory that provides early hardware-level pointers to critical startup components before standard UEFI execution begins. This article explores the architecture of the FIT, its role in the pre-boot environment, and how it enables firmware update mechanisms—such as UEFI Capsule updates—to locate, relocate, and validate essential assets like processor microcode and security modules without hardcoded memory offsets.

What Is the Firmware Interface Table?

The Firmware Interface Table is a structured data table defined primarily by Intel for modern x86 architectures. It resides inside the SPI flash memory and is referenced by a fixed pointer located at memory address 0xFFFFFFC0 (16 bytes below the 4 GB boundary, just below the traditional x86 reset vector).

When the processor comes out of reset, hardware logic automatically checks this address. If a valid FIT pointer is present, the processor's microcode parses the table prior to executing the first instruction at the reset vector.

The FIT consists of a series of 16-byte entries, each defining:

  • Address: The physical base address of the component in memory/flash.
  • Size: The size of the component (encoded in 16-byte chunks).
  • Version: The component or entry version.
  • Type: The identifier for the component type (e.g., Microcode Update, Startup Authenticated Code Module [ACM], BIOS Boot Guard policy, TPM configuration).

How the FIT Assists in Locating Components During UEFI Updates

Firmware updates are complex operations because firmware volumes, microcode patches, and security modules vary in size across releases. The FIT serves as an abstraction layer between the hardware execution engine and the physical flash layout, streamlining updates in several key ways.

1. Decoupling Code Locations from Fixed Offsets

Without the FIT, the system architecture would require microcode, authenticated code modules, and security manifests to reside at rigid, unchangeable memory locations. During a UEFI update (such as a Capsule Update), an updated microcode patch or security binary might exceed the allocated space of its previous version.

Because the CPU relies on the FIT rather than hardcoded flash addresses, the UEFI update utility can write newer, larger binaries to different areas in the flash memory and simply update the corresponding address and size fields in the FIT.

2. Synchronizing Microcode and ACM Discovery

Modern security frameworks, such as Intel Boot Guard, require the processor to locate and execute an Authenticated Code Module (ACM) before running UEFI initialization code (the SEC phase). During a firmware update:

  • The flasher writes the updated ACM and microcode patches into the SPI flash.
  • The flasher writes the new FIT table containing the updated physical pointers.
  • Upon the subsequent reboot, the hardware reads the FIT to instantly identify where the updated ACM and microcode reside, ensuring that early security validation happens seamlessly on the new code base.

3. Facilitating Multi-Microcode Matching

A single UEFI firmware image often supports multiple processor steppings or models. During an update, multiple microcode updates are loaded into flash. The FIT allows firmware creators to register multiple microcode entries (Type 0x01). During early boot post-update, the processor iterates through the FIT entries to locate, match, and apply the specific microcode patch that matches its internal CPUID and platform ID without relying on full UEFI driver execution.

4. Atomic Updates and Flash Layout Reorganization

When performing an update, flash tools often stage new images into alternative or backup banks (A/B layout). Because the FIT pointer at 0xFFFFFFC0 is the single source of truth for early boot assets, switching active banks or modifying layout structures during an update only requires pointing the top-level vector or FIT base to the new partition. The system avoids scanning through megabytes of unmapped flash to find needed runtime and boot components.