Purpose of UEFI Loaded Image Protocol

This article provides an overview of the Unified Extensible Firmware Interface (UEFI) Loaded Image Protocol, detailing how the firmware uses it to track and inspect executing binaries. It explores the protocol's primary data fields, its role in lifecycle management, and its critical function in debugging, system security, and memory profiling within the pre-boot environment.

Defining the Loaded Image Protocol

In the UEFI architecture, every executable—whether it is a DXE driver, a UEFI application, or an operating system bootloader—is treated as an image. When an image is loaded into system memory using the core boot service LoadImage(), the firmware creates a unique handle for that image. The firmware then installs the EFI_LOADED_IMAGE_PROTOCOL directly onto this newly created image handle.

The primary purpose of this protocol is to serve as the definitive descriptor for the active binary, exposing essential metadata about its origin, current memory location, and operational parameters.

Locating and Identifying Binaries in Memory

A core function of tracking executing binaries is knowing where they reside in physical memory. The EFI_LOADED_IMAGE_PROTOCOL interface contains two vital fields for this purpose:

  • ImageBase: A pointer to the starting address in memory where the binary's image was relocated and loaded.
  • ImageSize: The total continuous size of the loaded binary in bytes.

By providing these boundaries, the protocol allows runtime debuggers, crash loggers, and system profilers to map instruction pointers back to specific binaries. When a fault occurs, exception handlers inspect these fields across known image handles to identify which module triggered the exception and to load the corresponding symbol tables for stack unwinding.

Tracing Provenance and Source Media

The Loaded Image Protocol links an executing binary to its physical or logical storage source. It tracks provenance through:

  • DeviceHandle: Points to the handle of the device from which the image was fetched, such as a specific NVMe drive, USB partition, or network interface.
  • FilePath: Points to an EFI_DEVICE_PATH_PROTOCOL structure containing the precise filesystem path or Firmware Volume (FV) GUID where the binary originated.

This capability is essential for tracking boot chains. It allows binaries to load secondary files (such as configuration files or auxiliary drivers) relative to their own source location, and it enables logging mechanisms to record exactly which device initiated a given process.

Managing Binary Lifecycles and Execution Chains

The protocol also tracks the relationship between parent and child processes. Through the ParentHandle field, an executing image retains a reference to the binary or firmware component that invoked it. This establishes an auditable execution chain from the initial firmware platform initialization down to the OS loader.

Additionally, the protocol facilitates binary lifecycle control:

  • Execution Arguments: The LoadOptions and LoadOptionsSize fields store command-line parameters passed to the executable upon launch.
  • Clean Termination: The protocol contains an Unload function pointer. When an image needs to be terminated or removed from memory via UnloadImage(), the firmware calls this routine to allow the binary to free allocated resources, uninstall protocols, and safely shut down.

Role in Security and Measurement

Modern UEFI systems rely on tracking executing binaries to enforce platform security. During Secure Boot and Measured Boot workflows, platform firmware must verify signatures and record cryptographic hashes of executables into the Trusted Platform Module (TPM).

The EFI_LOADED_IMAGE_PROTOCOL acts as the anchor point for these security mechanisms. Security drivers locate the protocol to inspect the raw image data at ImageBase, verify that the binary has not been tampered with in memory, and measure the binary into TPM Platform Configuration Registers (PCRs) before execution is permitted.