How UEFI Verifies PCIe Option ROM Integrity

Unified Extensible Firmware Interface (UEFI) verifies the integrity of Option ROMs (OpROMs) on PCIe expansion cards primarily through the UEFI Secure Boot protocol, cryptographic signature validation, and Trusted Platform Module (TPM) measurements. By treating PCIe Option ROMs as loadable driver images rather than executing them as legacy raw binary payloads, UEFI applies standard Authenticode verification, platform key hierarchies, and revocation databases before allowing any code on the peripheral to execute.

UEFI Secure Boot and the Authenticode Architecture

Under UEFI, modern Option ROMs contain UEFI drivers packaged as standard PE/COFF (Portable Executable/Common Object File Format) 32-bit or 64-bit binaries. When a PCIe card is initialized, the UEFI firmware discovers the ROM on the PCIe bus, reads its Expansion ROM Header, and identifies the UEFI image within.

Before execution, the firmware checks this binary using Microsoft Authenticode standards:

  • Digital Signatures: The vendor signs the UEFI driver using a cryptographic certificate.
  • Integrity Hashing: The signature embeds an SHA-256 (or stronger) hash of the binary image to guarantee it has not been altered or corrupted.

Database Validation: db and dbx

The firmware verifies the Option ROM’s certificate against internal Non-Volatile RAM (NVRAM) key stores managed by the platform:

  1. Authorized Signature Database (db): The firmware checks if the certificate used to sign the PCIe driver matches an entry in the db (such as the Microsoft UEFI Driver Authority or the hardware OEM's key). If the certificate or the binary's hash is explicitly present in the db, it passes verification.
  2. Forbidden Signature Database (dbx): The firmware cross-references the driver against the revocation list (dbx). If the signing key has been revoked or the image hash matches a known vulnerable or malicious Option ROM, the firmware immediately rejects the code.

This process relies on the Platform Key (PK) and Key Exchange Key (KEK) hierarchy, ensuring that unauthorized third parties cannot alter the lists of trusted or revoked ROM signatures.

Measured Boot via the TPM

In addition to signature verification, modern systems log Option ROMs via Measured Boot using a Trusted Platform Module (TPM):

  • PCR Measurement: Before the Option ROM driver executes, the firmware calculates a cryptographic hash of the ROM binary.
  • Platform Configuration Register 2 (PCR 2): This hash is extended into PCR 2 of the TPM chip, which is specifically designated for add-in card firmware and Option ROMs.
  • Remote Attestation: Even if an unsigned or altered ROM were to execute (for instance, on a system where Secure Boot is disabled), the altered measurement in PCR 2 breaks the known-good cryptographic seal, preventing access to disk encryption keys or failing remote attestation checks.

Policy Enforcement and Legacy Fallback Prevention

If an Option ROM fails signature validation and Secure Boot is enabled, UEFI firmware halts the driver execution, typically displaying a Security Violation message or silently disabling the expansion card’s boot capabilities while allowing the operating system to load without peripheral firmware support.

To eliminate bypass vectors, systems with Secure Boot enforce pure UEFI execution by disabling the Compatibility Support Module (CSM). This prevents PCIe devices from executing legacy, unverified 16-bit real-mode x86 code (traditional PC-BIOS Option ROMs), ensuring that every piece of executable expansion code is subjected to cryptographic integrity checks.