UEFI Component Name Protocol Explained

The Unified Extensible Firmware Interface (UEFI) Component Name protocol provides a standardized mechanism for UEFI drivers to expose human-readable names for themselves and the hardware controllers they manage. This article explains the primary functions of the protocol, how it manages driver and controller identification, its support for international localization, and its practical importance within the UEFI pre-boot environment.

In the UEFI architecture, drivers, devices, and buses are identified internally using programmatic handles, binary protocols, and Globally Unique Identifiers (GUIDs). While optimal for firmware execution, these numerical identifiers are indecipherable to end users and system administrators. The EFI_COMPONENT_NAME2_PROTOCOL (along with its predecessor, EFI_COMPONENT_NAME_PROTOCOL) bridges this gap by allowing a driver to attach localized, plain-text descriptions directly to its handles.

The protocol provides two primary member functions to retrieve descriptive strings:

• GetDriverName: Returns a human-readable name for the driver itself, such as "Intel Gigabit Ethernet Network Driver" or "AHCI SATA Controller Driver." This describes the software component executing in the firmware.
• GetControllerName: Returns a plain-text name for a specific device or child controller managed by the driver, such as "PCI Gigabit Network Connection" or "Port 0: Samsung SSD 980." This allows individual peripheral instances to be clearly distinguished.

A critical feature of the Component Name protocol is native support for localization. The protocol defines a SupportedLanguages attribute, which lists the language codes the driver can provide. When querying GetDriverName or GetControllerName, the caller specifies the desired language tag based on RFC 4646 standards (such as en-US, fr-FR, or zh-Hans). If the requested language is supported, the protocol returns the localized string; otherwise, it returns an unsupported error, allowing the caller to fall back to a default language.

The modern EFI_COMPONENT_NAME2_PROTOCOL replaced the original EFI_COMPONENT_NAME_PROTOCOL to modernize language handling. The original protocol utilized three-character ISO 639-2 language codes (such as eng), whereas EFI_COMPONENT_NAME2_PROTOCOL aligns with newer UEFI specifications by using flexible RFC 4646 language tags.

In practice, the Component Name protocol is heavily utilized across the pre-boot ecosystem. Firmware setup utilities (the BIOS configuration screen) query this protocol to display meaningful device names in boot order menus and hardware health monitors. Additionally, the UEFI Shell relies on it to populate the output of diagnostic commands like drivers, devices, and dh (dump handle), transforming raw hexadecimal addresses into readable diagnostics that make debugging and system administration feasible.