How to Test UEFI Storage Driver Compliance

Firmware engineers ensure storage driver compliance against the UEFI specification through a structured verification process that combines the official UEFI Self-Certification Test (SCT) suite, protocol-level validation, stress testing, and operating system boot handoff checks. This article outlines the primary methodologies, standardized tools, and testing procedures engineers use to validate that UEFI storage drivers—such as those for NVMe, SATA AHCI, and UFS—function reliably, manage system resources correctly, and adhere strictly to the UEFI standard.

1. UEFI Self-Certification Test (SCT) Suite

The primary tool for verifying compliance is the UEFI SCT, an automated test harness maintained by the UEFI Forum. Engineers execute the SCT directly within the UEFI Shell to run assertions against the interfaces exposed by the storage driver. The SCT checks:

  • Protocol Compliance: Verifies standard storage protocols, including EFI_BLOCK_IO_PROTOCOL, EFI_BLOCK_IO2_PROTOCOL (for asynchronous operations), EFI_DISK_IO_PROTOCOL, and EFI_STORAGE_SECURITY_COMMAND_PROTOCOL.
  • API Invariants: Validates that parameters, return statuses, buffer alignments, and boundary conditions match the exact signatures and expected behaviors documented in the UEFI Specification.
  • Failure Code Accuracy: Ensures the driver returns standard status codes (such as EFI_DEVICE_ERROR, EFI_INVALID_PARAMETER, or EFI_NO_MEDIA) under deliberate fault conditions rather than hanging or returning non-standard values.

2. UEFI Driver Model Validation

Storage drivers must conform to the standard UEFI Driver Binding Model. Engineers evaluate compliance using built-in UEFI Shell commands and specialized test scripts that invoke:

  • Supported(): Verifies that the driver correctly probes hardware controllers and claims only compatible devices without claiming foreign handles.
  • Start(): Tests whether the driver initializes hardware, allocates memory pools, establishes event queues, and installs the required child handles and protocols properly.
  • Stop(): Verifies clean teardown. Engineers repeatedly start and stop the driver to ensure all child handles are uninstalled, interrupt/timer events are closed, and memory buffers are freed without leaks.

3. Asynchronous I/O and Queue Handling

Modern storage devices rely heavily on non-blocking and queued operations via EFI_BLOCK_IO2_PROTOCOL. Firmware engineers test this functionality by:

  • Triggering concurrent read and write tokens to verify that command queues do not deadlock or drop transactions.
  • Checking that notification events (EFI_EVENT) signal completion accurately and invoke registered callbacks.
  • Simulating hardware timeouts to confirm that the driver can abort transactions or reset submission/completion queues gracefully.

4. Boundary, Alignment, and Stress Testing

Engineers employ targeted synthetic workloads to verify robust handling of irregular access patterns:

  • Buffer Alignment: Testing transfers across non-standard memory boundaries, such as buffers unaligned to the drive’s logical block addressing (LBA) size or controller DMA boundary constraints.
  • Extreme LBA Access: Issuing read and write requests to LBA 0, the final addressable LBA of the drive, and out-of-range blocks to verify bounds-checking.
  • Heavy Concurrent Load: Executing sustained read, write, and flush operations across extended durations to detect edge-case race conditions and memory corruption.

5. OS Handoff and ExitBootServices Verification

A compliant UEFI storage driver must safely transition control to the operating system:

  • ExitBootServices() Cleanliness: The driver must register an event callback for EVT_SIGNAL_EXIT_BOOT_SERVICES to disable active DMA engines, clear hardware interrupts, and neutralize controller states so that incoming operating system native drivers inherit clean hardware.
  • OS Installation and Boot: Engineers validate end-to-end functionality by installing and booting major operating systems (e.g., Linux, Windows) from the target drive using their native EFI bootloaders.