What Is the UEFI Loaded Image Device Path Protocol?

This article provides an overview of the Unified Extensible Firmware Interface (UEFI) Loaded Image Device Path Protocol, detailing its purpose, technical significance, and role during system initialization. It explains how this protocol complements the standard Loaded Image Protocol by specifying the exact storage location and hardware pathway of an executing UEFI image, allowing bootloaders, drivers, and operating system kernels to discover where they were loaded from and locate associated runtime files.

Definition and Core Purpose

The UEFI Loaded Image Device Path Protocol (EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL) is a standard protocol defined in the UEFI Specification. Its primary purpose is to expose the exact hardware and logical device path from which an executable image (such as an application, bootloader, or driver) was originally retrieved.

When the UEFI firmware loads an executable PE/COFF binary into memory using the gBS->LoadImage() boot service, it creates an image handle. The firmware typically installs two key protocols onto this handle:

  1. EFI_LOADED_IMAGE_PROTOCOL: Provides runtime execution details, such as the memory base address, image size, execution options, and the handle of the device where the image was stored.
  2. EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL: Specifies the exact EFI_DEVICE_PATH_PROTOCOL that points directly to the file on the media from which the image was loaded.

While the standard Loaded Image Protocol references the storage device handle, it does not directly contain the complete, granular device path to the specific binary file. The Loaded Image Device Path Protocol bridges this gap by providing the full node-by-node path, from the host controller down to the specific file system partition and file path.

Key Use Cases

1. Locating Configuration Files and Secondary Payloads

Bootloaders (such as GRUB or systemd-boot) rarely operate in complete isolation; they frequently require access to secondary files, including configuration files, initial RAM disks (initrd), or operating system kernels located in the same directory or partition. By querying the Loaded Image Device Path Protocol on its own image handle, a bootloader can parse the device path, determine its own storage location, and open relative files from the same file system without hardcoding partition identifiers.

2. Determining the Boot Medium

Operating systems and diagnostic utilities often need to identify the exact physical or network interface used to boot the platform. Because the protocol returns a standard UEFI device path, an application can traverse the path nodes to detect whether the image was booted from an NVMe drive, a SATA controller, a USB mass storage device, or via PXE/HTTP over a specific network interface.

3. Security and Policy Enforcement

Security tools and platform verification mechanisms inspect the device path to ensure that an executing binary originates from an authorized source. Firmware security policies can compare the device path against whitelists or check if the binary was loaded from an external, untrusted media source versus an internal, measured platform storage component.

Technical Implementation

In C-based UEFI development, the protocol uses the same internal data structure as the standard device path protocol (EFI_DEVICE_PATH_PROTOCOL). It is differentiated by its unique Globally Unique Identifier (GUID):

#define EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID \
  { 0xbc62157e, 0x3e33, 0x4fec, { 0x99, 0x20, 0x2d, 0x3b, 0x36, 0xd7, 0x50, 0xdf } }

An application obtains this protocol by calling the OpenProtocol boot service using its own ImageHandle:

EFI_DEVICE_PATH_PROTOCOL *DevicePath;

Status = gBS->OpenProtocol(
    ImageHandle,
    &gEfiLoadedImageDevicePathProtocolGuid,
    (VOID **)&DevicePath,
    ImageHandle,
    NULL,
    EFI_OPEN_PROTOCOL_GET_PROTOCOL
);

Once acquired, the binary can pass this device path to the DevicePathToText utility protocols to convert it into a human-readable string or use it with file system protocols to open the parent directory.