UEFI Decompress Protocol in Firmware Images

This article explains the critical role of the Unified Extensible Firmware Interface (UEFI) Decompress protocol in modern boot processes, detailing how system firmware manages storage constraints by unpacking executable binaries. By serving as a standardized bridge between tightly packed storage and memory execution, the UEFI Decompress protocol enables platforms to unpack and dispatch compressed Firmware Volumes (FVs) during system initialization, balancing platform ROM limitations with rich pre-boot functionality.

The Purpose of Firmware Compression

Modern hardware platforms require an extensive array of initialization drivers, hardware setup routines, diagnostic tools, and boot managers before transferring control to an operating system. However, motherboard flash memory (typically SPI NOR flash) has strict physical size constraints due to cost and board layout limits.

To overcome these constraints, hardware vendors compress UEFI drivers, applications, and core libraries within firmware volumes. Compressing these binaries allows significantly more functionality to fit onto a standard 16 MB or 32 MB flash chip. However, the processor cannot execute compressed code directly from flash. It must be unpacked into system RAM, which is where the UEFI Decompress protocol becomes essential.

Core Architecture of the UEFI Decompress Protocol

The UEFI Decompress protocol, formally identified as EFI_DECOMPRESS_PROTOCOL, provides a unified interface for decompressing data blocks using standard decompression algorithms defined by the UEFI Specification.

The protocol exposes two primary member functions:

  • GetInfo(): Inspects the compressed data stream to determine the size of the uncompressed output buffer and the size of any temporary scratch buffer required during the decompression routine. This allows the calling firmware component to allocate the exact memory buffers needed before processing.
  • Decompress(): Reads the compressed input stream, uses the allocated scratch space for intermediate calculations, and reconstructs the original uncompressed binary into the target destination buffer.

The standardized algorithm natively mandated by the UEFI specification relies on a variant of Lempel-Ziv-Storer-Szymanski (LZSS) combined with adaptive Huffman coding, optimized to execute efficiently in resource-constrained environments.

The Unpacking and Execution Workflow

The extraction and execution of compressed firmware images follow a precise sequence during the boot phase, typically orchestrated during the transition between the Pre-EFI Initialization (PEI) phase and the Driver Execution Environment (DXE) phase:

  1. Discovery: The firmware detects a section within a Firmware Volume marked with the section type EFI_SECTION_COMPRESSION.
  2. Buffer Allocation: The Firmware Volume dispatch engine invokes GetInfo() to evaluate the size requirements for the target buffer and scratch memory. The firmware then requests system memory allocations (via standard boot service memory allocation functions).
  3. Extraction: The Decompress() function runs, unpacking the raw PE32/PE32+/COFF image from flash memory into the newly allocated system RAM.
  4. Authentication and Relocation: Once decompressed into RAM, security checks (such as Secure Boot signature verification or cryptographic hashing) inspect the uncompressed image, and internal relocation fix-ups are applied.
  5. Dispatch: The DXE dispatcher transfers control to the entry point of the decompressed driver, allowing it to initialize hardware or introduce additional platform protocols.

Performance and Reliability Benefits

Using a dedicated decompression protocol offers several system advantages beyond raw space reduction:

  • Bus Bandwidth Optimization: Reading smaller, compressed blocks across slower external buses (such as SPI) and decompressing them in high-speed RAM can often yield faster boot times than reading uncompressed, larger binaries directly from slow storage.
  • Standardization: By abstracting the decompression logic behind an architectural protocol, the UEFI core decouples individual drivers from needing bespoke unpacking logic, keeping base drivers lightweight.
  • Modularity: Firmware developers can replace or augment the default decompression mechanisms with custom algorithms (such as platform-specific Tiano or custom LZMA protocols) without altering how the firmware volume dispatcher discovers and loads target images.