Understanding System Firmware and its Relationship to UEFI
In recent years, the industry discussions and press reports related to “Platform Firmware”, “System Firmware”, or “Host Firmware” and its flaws and vulnerabilities refer to the firmware as “UEFI.” That is an easy leap to make as system firmware complying with the UEFI standard has largely replaced BIOS (Basic I/O System) in x86 personal computers and servers. UEFI, as an interface standard, is also widely adopted on Arm-based servers, DPU/IPUs, edge and IoT devices even though these systems never used BIOS. In addition, the UEFI interface standard is also supported on RISC-V and Loongson-based systems. Therefore, system firmware complying with the UEFI standard is used on a significant range of devices with computing and networking capabilities. Replacing one four letter acronym with another is an easy thing to do. The problem is that the system firmware that initializes hardware and loads software in these systems is very complex, as will be described below. It is a misnomer to apply the UEFI label to all system firmware implementations and doing so drives confusion and misunderstandings with end users.
This is not to say that implementation flaws and design vulnerabilities are not a big deal. Compromised firmware can have a serious effect on the operation and security of systems, and it may be possible to gain malware persistence that resists system resets and software reinstallation. This paper will not attempt to excuse or minimize these effects. It attempts to educate readers about the complexities involved and show that there isn’t a silver bullet of “following best practices,” or similar, that will provide a simple solution to “just fix it.”
Introduction
What is “UEFI”? The Unified Extensible Firmware Interface standard is an international standard describing a consistent way for firmware on a computing platform to interact with operating systems that are loaded into memory by it. It has various security features including Secure Boot, Secure Update, and others. The standard is maintained by the UEFI Forum, a nonprofit industry standards body, with an open membership. UEFI, as the name describes, defines the interface, not the implementation. There are many different system firmware implementations out there that are complying with this UEFI standard interface.
A Very Brief History
BIOS was created in the late 1970s to provide load and basic I/O services to operating systems on the original x86 PCs. It became a de facto standard for these x86 PCs and servers. In the late 1990s, new and more complex processor types were becoming available where continued use of BIOS, that is tied to the x86 architecture, just did not make sense. The Extensible Firmware Interface design was created to replace the way BIOS and OSes communicate on systems with Intel CPUs. Eventually, the UEFI Forum was formed in 2005 to make the standard interface more open, broaden its usage, and allow the system firmware community to participate in maintenance and further development of the standard.
The Specifications The UEFI Forum actively maintains several interrelated specifications.
- PI Specification (Platform Initialization)
Originally catering exclusively to Intel CPU architectures, the PI Spec has recently expanded to embrace Arm and anticipated RISC-V architectures. This specification delineates the process of initializing a platform, spanning from power-on to operating system load. PI provides one possible implementation of UEFI with the UEFI DXE components providing the ‘kernel’ or core services found in the UEFI specification. Note: For Arm A-profile based systems, Trusted Firmware is used for the initial platform initialization phase. The next stage of the platform initialization may, or may not, be PI Specification compliant depending on the implementations, even if the system firmware is UEFI compliant. Trusted Firmware also provides additional interfaces to the operating system that are Arm-specific and not governed by the PI, UEFI or ACPI specifications. - UEFI Specification (Unified Extensible Firmware Interface)
The UEFI specification outlines an interface for firmware to interact with the operating system and the boot drivers, incorporating elements such as Secure Boot and Secure Update to bolster security. Managed by the UEFI Forum, this specification defines the interface only, avoiding prescription of specific implementations. Note: While large in scope, much of the UEFI specification is optional and vendors may choose what portions of it are needed for their systems. - ACPI Specification (Advanced Configuration and Power Interface)
The ACPI specification defines power management, enumeration of devices on buses without standard discovery mechanism, and configuration interfaces. It encapsulates various aspects of system management, including devices, power control, facilitating hardware abstraction for the operating system. A popular alternative to ACPI, especially on embedded devices, is Device Tree, providing description of the hardware, but not a control abstraction to the operating system.
Implementations As the UEFI Specifications do not specify an implementation, only an interface, several implementations have been developed.
- Open Source
- Tianocore is a community-driven open-source project that builds upon the EDK II codebase. It offers a code repository for UEFI firmware development, including support for new hardware standards, features, and enhancements. Tianocore has gained popularity for its versatility and robustness.
- UBoot is a popular open-source bootloader commonly used in embedded systems and devices. It provides the initial boot and setup functionality for a system, loading and executing the operating system or other software components.Starting with its 2021.04 release, UEFI interface is added to the UBoot project, enabling UBoot to support OS boot loaders such as grub, and to support UEFI-based Secure Boot and Secure Firmware Update mechanisms.
- LinuxBoot is another popular open-source bootloader, currently used in server systems deployed by some of the cloud service providers. LinuxBoot uses Linux as the system firmware implementation, enabling Linux drivers for the boot devices to be used in the boot environment. LinuxBoot may or may not use Tianocore EDK II code to assist the passing of the ACPI information as well as some UEFI runtime services to the operating system. LinuxBoot currently does not officially support the UEFI boot services to the operating system as it kexec’s to Linux directly. However, the LinuxBoot community has been interested and is working on adding a UEFI payload to support the UEFI boot services such that the full UEFI interface can be supported by LinuxBoot as well to allow the other generic operating systems to work as well. In fact, when this is properly done, the operating system should not care or know whether the underline implementation is Tianocore EDK II or LinuxBoot.
- coreboot is an open-source firmware project for many system architectures. It provides similar capabilities to UEFI PI PEI with its romstage and UEFI PI DXE with its ramstage. In some cases, it may also provide UEFI defined interfaces via its payload mechanism, using things like the UEFI Payload Package of EDKII.
- Proprietary implementations that can be licensed from Independent Firmware Vendors (IFVs). These implementations may be based on one or more of the above open-source projects.
- Phoenix SecureCore
- AMI Aptio V
- Insyde’s InsydeH2O
- Proprietary system firmware implementations, that may, or may not, be fully conformant to the UEFI specification.
- Apple EFI – Apple’s EFI firmware on MacBooks with Intel Silicon, while unique to its ecosystem, shares commonalities with standard UEFI implementations.
- Historically, there were many other implementations. For example, Intel had UEFI layered on top of BIOS. HP had UEFI layered on top of two different proprietary codebases.
- There are others not captured here.
This illustrates that, while UEFI is a standard interface definition, there can be many different implementations. It is not one size fit all. The system firmware that initializes hardware and loads software in these systems is indeed very complex. It is not just one thing named “UEFI.” In fact, there is no “one thing” that is UEFI.
