Legacy API Deprecation in UEFI Specifications

This article outlines the governance, architectural criteria, and transitional protocols the Unified Extensible Firmware Interface (UEFI) Forum uses to deprecate legacy Application Programming Interfaces (APIs). As hardware platforms evolve, older interfaces become security risks or architectural bottlenecks, prompting the UEFI specification working groups to systematically flag, phase out, and replace legacy protocols while maintaining system interoperability.

The Engineering Change Request (ECR) Process

API deprecation begins through an Engineering Change Request (ECR) submitted to the UEFI Specification Working Group (USWG). The proposing member must demonstrate:

  • Technical justification: Why the existing API or protocol is redundant, computationally inefficient, or insecure.
  • Functional replacement: A modern, standardized replacement protocol capable of handling current hardware demands (such as switching from legacy 32-bit interfaces to 64-bit-native interfaces).
  • Impact assessment: An analysis of existing operating system boot loaders, option ROMs, and pre-boot applications that rely on the legacy call.

Formal Specification Tagging

When an ECR for deprecation is approved:

  • The specific API, protocol GUID, or data structure is annotated in the official UEFI Specification text with a "Deprecated" designation.
  • The documentation details the exact specification version in which the deprecation took effect.
  • The specification references the modern protocol that must be adopted in place of the deprecated component.

Source-Level Deprecation in Reference Implementations

Deprecation moves from documentation to code through TianoCore EDK II, the open-source reference implementation of UEFI:

  • Header Annotations: Function pointers and structure definitions in C headers are marked using compiler-specific deprecation macros (such as GCC’s __attribute__((deprecated)) or MSVC’s __declspec(deprecated)).
  • Build Flags: Platform build configuration files (DSC and DEC files) introduce feature flags such as DISABLE_NEW_DEPRECATED_INTERFACES or MdePkg deprecation flags. These flags generate build-time warnings or hard errors if firmware code attempts to invoke the deprecated symbols.

Binary Compatibility and Grace Periods

The UEFI Forum enforces a multi-version grace period to prevent breaking pre-boot environments across hardware generations:

  • Non-Immediate Removal: Deprecated APIs are rarely deleted immediately from the specification. They remain defined in the spec across subsequent releases to preserve Application Binary Interface (ABI) stability for legacy payloads.
  • Return-Value Stubs: During transition phases, firmware implementations often retain the deprecated function pointer in system tables, but modify the underlying implementation to return EFI_UNSUPPORTED or a functionally restricted result if hardware no longer supports the call.
  • Firmware-OS Boundary Protection: Core runtime and boot services essential to OS loaders remain functional longer than internal driver-to-driver protocols, ensuring operating systems developed for older revisions can still boot on newer firmware.

Security-Driven Accelerated Deprecation

Standard deprecation cycles are bypassed when cryptographic vulnerabilities are identified. For insecure hashing algorithms, obsolete cipher suites, or vulnerable variable storage methods, the UEFI Security Sub-Team expedites the deprecation timeline. In these scenarios, older APIs are replaced with modern cryptographically agile interfaces in point releases, and reference code is quickly configured to reject legacy algorithms by default.