How UEFI Validation Suites Test Firmware Compliance
UEFI firmware validation suites ensure that modern system firmware strictly adheres to the specifications defined by the UEFI Forum. These suites systematically evaluate boot services, runtime interfaces, hardware protocols, and security implementations by executing automated test scripts across pre-boot and post-boot environments. By running standardized functional tests, boundary analysis, and negative test cases, validation suites verify that independent hardware vendor (IHV) and original equipment manufacturer (OEM) firmware behaves predictably and safely across diverse operating systems and hardware platforms.
The Self-Certification Test (SCT) Harness
The cornerstone of compliance testing is the UEFI Self-Certification Test (SCT), managed directly by the UEFI Forum. The SCT operates inside the native UEFI shell environment before any operating system loads. Once initialized, the test harness parses the platform's active configuration and executes thousands of standardized test assertions.
The harness iterates through all registered handles, protocols, and
standard services. For each test assertion, the suite invokes a specific
API, passes defined inputs, and validates the returned status codes and
output buffers against the exact requirements set forth in the UEFI
Specification. If a function returns an unexpected status code (such as
returning EFI_SUCCESS instead of
EFI_INVALID_PARAMETER when passed a null pointer), the
assertion fails and logs a compliance violation.
Verification of Boot and Runtime Services
Validation suites divide core functional testing into Boot Services and Runtime Services:
- Boot Services: The suite tests memory allocation services, event timers, task priority levels (TPL), image loading functions, and device path utilities. It validates whether memory maps are accurately reported, memory descriptors do not overlap, and allocated pages are properly freed when transitions occur.
- Runtime Services: Tests verify calls that persist
after the operating system takes control, notably
GetVariable,SetVariable, time services, and system reset capabilities. Compliance suites evaluate whether Non-Volatile RAM (NVRAM) variables are properly isolated, read-only attributes are respected, and calls made at runtime do not access boot-time-only memory regions.
Protocol and Device Driver Conformance
Every UEFI driver exposes interfaces using globally unique identifiers (GUIDs). Validation suites scan the system handle database to ensure that standard protocols—such as the Graphics Output Protocol (GOP), Simple Network Protocol (SNP), Block I/O, and PCI Root Bridge I/O—comply with the required function signatures and state machines.
The suite simulates I/O operations by reading and writing to block storage, initiating network handshakes, or changing display modes. It ensures that protocol revisions match the specification and that device paths conform to standard binary representations.
Operating-System-Level Validation Suites
Compliance verification continues after the operating system boots. Tools such as the Linux Firmware Test Suite (FWTS) inspect the handoff state between firmware and the kernel.
FWTS checks the integrity of the ACPI (Advanced Configuration and
Power Interface) tables generated by the UEFI firmware, verifies runtime
variable accessibility through kernel interfaces (like
efivarfs), and tests power management transitions (such as
sleep and resume states). This phase ensures that the firmware’s runtime
handoff mechanisms do not crash or destabilize an active operating
system kernel.
Security and Secure Boot Validation
Validation suites place heavy emphasis on testing the UEFI Secure
Boot implementation. The suite attempts to load and execute images
signed with valid keys, expired keys, untrusted keys, and signatures
explicitly revoked in the dbx (Forbidden Signature
Database).
To achieve compliance, the firmware must flawlessly accept legitimate binaries and reject unauthorized or altered images without exception. The validation suite also verifies that authenticated variable updates to the platform key (PK) and key exchange key (KEK) databases require the correct digital signatures before allowing state changes.
Negative and Boundary Testing
A critical aspect of compliance testing involves intentionally feeding malformed, out-of-range, or corrupted data to firmware entry points. Validation suites test system resilience by providing invalid pointers, zero-length buffers, mismatched data sizes, and corrupted file system structures. Compliant firmware must cleanly reject invalid input via appropriate error handling mechanisms rather than hanging, faulting, or exposing memory corruption vulnerabilities.