Beyond the Surface: Other Components in the Image
As described in part 1, there are many implementations of system firmware that have been developed from many source roots. In addition to that, all these firmware systems typically pull code from other sources, open-source and proprietary, some in source code format and some as pre-compiled binary “blobs.”
- Chip Vendor Code
Chip vendors (Silicon Providers or SiPs) contribute essential low-level code to enable hardware communication and functionality. - Open-Source Implementations
Code implementing typical UEFI requirements and features. - 3rd Party Binary Blobs or Source Modules
Firmware may include unchanged binary blobs or source modules from third-party vendors, potentially introducing vulnerabilities. - Trusted Platform Module (TPM) Support
Trusted Platform Module (TPM) support, whether from dedicated TPM vendors or firmware based TPM (fTPM) code, contributes cryptographic and security features. Interfaces to the TPM are maintained by a related standards body called the Trusted Computing Group (TCG). The latter publishes the UEFI APIs to abstract the TPM. - Customer Features developed by OEMs
Firmware allows for customization and introduction of unique features, although the security implications need meticulous consideration. - Encryption/Decryption and Hashing Support
Encryption capabilities integrated into the firmware bolster data security and integrity. These frequently come from open-source projects like OpenSSL. - Special Processor Mode Support (SMM/TrustZone)
Special modes like System Management Mode (SMM) or ARM TrustZone introduce isolated execution environments, enhancing security. - Binary Blobs or Source Modules
Firmware may include unchanged binary blobs or source modules from third-party vendors, potentially introducing vulnerabilities. - IFV/IBV Added Value Customizations
Features added by Independent Firmware Vendors (IFVs/IBVs). - Device Firmware
There may be other Device Firmware, or the plurality of embedded firmware that executes on I/O devices, SOC microcontrollers, embedded controllers, and baseboard management controllers (BMCs) on a modern client system. A single system firmware image may include many instances of ‘device firmware.’
Supply Chain Dynamics
When a platform enters production, the UEFI compliant firmware that powers on that device is the collaborative product of numerous industry partners. Each partner’s contribution is passed on to the next until the production platform’s final UEFI compliant firmware image is finished. The UEFI specification makes this work, allowing each partner to add the pieces that are closely related to their specialty. There are many variations, with some partners taking on multiple roles.
Life for a UEFI compliant firmware image generally starts as a curated combination of open-source components (like Tianocore/EDK2), most often includes reference code from a silicon vendor (SiP), and depending on the development model, may include framework and/or feature modules from an IFV/IBV (independent Firmware/BIOS Vendor) that are targeted at specific reference pieces of hardware. This reference version, following the UEFI standards, allows a single OS image like those found in Windows or Linux to run on the amazing diversity of CPUs, silicon and platforms manufactured each year that run on UEFI-based firmware.
If involved in the supply chain, an ODM (Original Design Manufacturer) usually takes the upstream FW from an IBV/IFV or OEM (Original Equipment Manufacturer) development team and customizes it to meet the requirements of the specific platform and the requirements of the OEM.
The flexibility of the UEFI standard has helped this dynamic ecosystem evolve by supporting this model, but it also contributes to the difficulty of responding to security vulnerabilities. Each partner in the supply chain spends time evaluating the vulnerability, finding a mitigation, applying, and testing that mitigation to all the platforms they are working with, and then distributing a fixed version to the next partner.
This takes time. Time is the malware author’s friend. There is a balance between giving all partners a reasonable time to create fixes and reducing the time systems are without a patch. To make sure that one company’s security fix does not become another company’s zero-day attack, the UEFI Security Response Team (USRT) works with CERT/CC (Computer Emergency Response Team/ Coordination Center) to manage the disclosure process and make sure all partners in the supply chain work together to implement coordinated vulnerability disclosures.
This takes information. The last link in the supply chain is the platform owner. This might be an individual end-user, or it might be a company’s IT department. They are the least-informed partner, yet they are the partner that ultimately agrees to a security-related firmware update. To provide more visibility into the UEFI components, UEFI Forum’s SBOM Sub-Team (USBT) is drafting recommendations about how partners disclose a SBOM (Software Bill of Materials) with details of each component, its version, its source code, and a unique identifier. This SBOM is delivered to the next link in the supply chain, helping each to identify the contents of their UEFI compliant firmware and recognize when a publicly disclosed vulnerability might affect them. This aligns well with the ongoing Vulnerability Exchange (VEX) goals of the U.S. and other national governments.
The UEFI forum also reaches out to all partners in the supply chain with security best practices targeted to the unique security challenges of UEFI firmware, including threat modeling, coding standards, and training.
The UEFI community, working together, can help secure the diverse and creative ecosystem of UEFI firmware, one link in the supply chain at a time.
