Option ROM Execution in UEFI vs Legacy CSM Mode

Option Read-Only Memories (Option ROMs or OpROMs) provide device-specific firmware to initialize add-in hardware, such as storage controllers and graphics cards, during system startup. The execution of these ROMs differs significantly depending on whether the system runs in a native UEFI environment or uses the Compatibility Support Module (CSM) to emulate a legacy BIOS. While native UEFI executes OpROMs as modern, modular drivers in 32-bit, 64-bit, or processor-independent formats within a protected memory map, CSM executes them as legacy 16-bit real-mode binaries subject to strict physical memory limitations and dated interrupt handling.

Binary Formats and Architecture

In a legacy or CSM-enabled environment, an Option ROM consists of raw 16-bit x86 machine code. It begins with the standard legacy signature (0x55AA), followed by a single-byte length indicator and entry-point vectors. The processor must drop into 16-bit real mode (or Virtual 8086 mode) to execute this code, limiting instructions to standard x86 real-mode operations.

In a native UEFI environment, Option ROMs contain EFI drivers compiled as standard PE32+ (Portable Executable) binaries or EFI Byte Code (EBC). These drivers run natively in the system's target architecture—typically 64-bit long mode (x86_64 or AArch64)—without requiring processor state downgrades. UEFI drivers adhere to the UEFI Driver Model, producing protocols that attach cleanly to device handles managed by the UEFI core.

Memory Allocation and Execution Space

Legacy Option ROM execution is constrained by the historical PC memory architecture:

  • The 1MB Memory Hole: Legacy BIOS allocates OpROMs to the upper memory area between C0000h and EFFFFh (the Option ROM memory space). All expansion cards must compete for this narrow memory window, which rarely exceeds 128 KB to 192 KB in total usable space.
  • Size Limitations: If a card’s legacy OpROM exceeds available space within this window, it fails to initialize, often causing system hangs or non-bootable states.

Native UEFI eliminates these memory barriers:

  • Flat Memory Model: UEFI runs in flat, identity-mapped physical or virtual memory.
  • Dynamic Allocation: UEFI drivers inside the OpROM are loaded into standard system RAM through the AllocatePages() or AllocatePool() boot services. They can occupy megabytes of storage if required, easily accommodating advanced setup utilities, graphical configuration tools, and complex network stacks.

Discovery and Dispatching Mechanics

The execution sequence varies substantially between the two environments:

  1. CSM (Legacy) Discovery:
    • During the Power-On Self-Test (POST), the BIOS PCI enumerator identifies devices requiring an OpROM via their PCI configuration spaces.
    • The BIOS copies the ROM from the device into the C0000h–EFFFFh segment.
    • The BIOS invokes the ROM's initialization vector via a 16-bit FAR CALL.
    • The OpROM hooks the Interrupt Vector Table (IVT)—typically hijacking INT 10h for video, INT 13h for disk operations, or INT 19h for bootstrap routing according to the BIOS Boot Specification (BBS).
  2. UEFI Discovery:
    • The UEFI PCI Bus Driver scans the PCI bus and discovers the PCI Expansion ROM Base Address Register (BAR).
    • The driver parses the PCI Expansion ROM header to find a UEFI-compatible image (a single physical OpROM may contain both legacy and UEFI images via a linked-list PCI Data Structure).
    • The UEFI Security Architectural Protocol validates the binary's cryptographic signature if Secure Boot is enabled.
    • If verified, the DXE (Driver Execution Environment) dispatcher loads the PE32+ image into RAM and calls its entry point (EFI_IMAGE_ENTRY_POINT).
    • The driver installs EFI_DRIVER_BINDING_PROTOCOL, allowing the system to bind the driver to the device handle and access hardware resources through standard UEFI protocols rather than software interrupts.

Security and Validation

Under CSM, Option ROM execution provides no native integrity checking or cryptographic validation. Any arbitrary code embedded in the ROM is executed with full hardware privileges in real mode, making legacy OpROMs vulnerable to firmware-level rootkits and boot-path modifications.

Native UEFI integrates Option ROM execution directly into the Secure Boot chain of trust. Before the system executes an OpROM driver, the firmware validates the driver’s digital signature against authorized keys in the db (Signature Database) and ensures it is not listed in the dbx (Forbidden Signatures Database). If validation fails, execution is blocked, preventing unauthorized or tampered expansion firmware from compromising system initialization.