UEFI Image Subsystem Types in PE Headers

The subsystem type field in a Portable Executable (PE) header determines how the Unified Extensible Firmware Interface (UEFI) loads, executes, and manages the lifecycle of an executable image. Located within the PE Optional Header, this value dictates the memory allocation strategy, driver residency, and access permissions the image receives from the firmware environment. Understanding this field is critical for firmware developers and security researchers, as it defines whether an image functions as a transient boot-time program, a persistent hardware driver, or a service accessible to the operating system after boot.

The Role of the Subsystem Field in PE Headers

The PE/COFF specification uses the Subsystem field within the IMAGE_OPTIONAL_HEADER structure to signal to an operating system or firmware loader which execution environment the binary requires. While Windows uses this field to distinguish between GUI and command-line applications, the UEFI specification repurposes it to dictate the operational scope and execution model of pre-boot binaries.

When the UEFI Boot Services function LoadImage() reads a binary, it inspects this field to validate compatibility with the platform and determine how to allocate memory pages for the image's code and data sections.

Key UEFI Subsystem Types

The UEFI specification defines several specific subsystem values that replace standard OS-level designations:

  • IMAGE_SUBSYSTEM_EFI_APPLICATION (Value: 10 / 0x0A): Designates a standalone UEFI application, such as the UEFI Shell or an operating system bootloader (e.g., bootmgfw.efi or GRUB). Applications can call boot and runtime services, but their primary purpose is to execute a discrete task or transfer control to an OS kernel. When the application returns or calls ExitBootServices(), its memory can be reclaimed.
  • IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER (Value: 11 / 0x0B): Identifies a driver that initializes hardware or provides services exclusively during the pre-boot phase. These drivers are allocated memory of types EfiBootServicesCode and EfiBootServicesData. Once the OS loader calls ExitBootServices(), all resources associated with these drivers are released and reclaimed by the operating system.
  • IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER (Value: 12 / 0x0C): Designates a driver that must remain active even after the operating system has taken control of the hardware. The firmware allocates these images in EfiRuntimeServicesCode and EfiRuntimeServicesData memory regions. The operating system preserves these memory ranges and virtualizes them so that OS kernels can call runtime services (such as updating NVRAM variables or setting the system time).
  • IMAGE_SUBSYSTEM_EFI_ROM (Value: 13 / 0x0D): Intended for firmware images stored in read-only memory, typically option ROMs on expansion cards.

Technical Significance and Implications

The subsystem field is critical because it directly influences platform behavior in three key areas:

1. Memory Management and Allocation

The UEFI memory map categorizes memory based on the loading image's subsystem. If a runtime driver were mistakenly marked as a boot service driver, the operating system would overwrite its code space after boot, leading to kernel panics or system crashes during runtime calls. Conversely, marking a standard boot service driver as a runtime driver unnecessarily fragments and consumes protected physical RAM that the operating system cannot reclaim.

2. Virtual Address Remapping

Runtime drivers must support virtual memory address translation because the operating system switches the processor from physical addressing to virtual addressing via the SetVirtualAddressMap() runtime call. The subsystem field alerts the firmware that it must register the image's relocation fixups, allowing the OS kernel to remap the driver into kernel space.

3. Firmware Validation and Security

Firmware implementations use the subsystem type during security verification routines. Mismatched or unsupported subsystem values cause LoadImage() to fail immediately with an EFI_UNSUPPORTED error code. In Secure Boot environments, the subsystem type ensures that signed components cannot execute outside their designated privilege boundaries or intended operational contexts.