Campbell, CA  |

Phoenix Technologies Logo

Decoding UEFI Firmware: Unraveling the Intricacies of System Firmware, its Ecosystem and Supply Chain Part 2 of 3

green circuit board

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.”

Figure 1 – Some of the many components & elements of UEFI based firmware.
  1. Chip Vendor Code
    Chip vendors (Silicon Providers or SiPs) contribute essential low-level code to enable hardware communication and functionality.
  2. Open-Source Implementations
    Code implementing typical UEFI requirements and features.
  3. 3rd Party Binary Blobs or Source Modules
    Firmware may include unchanged binary blobs or source modules from third-party vendors, potentially introducing vulnerabilities.
  4. 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.
  5. Customer Features developed by OEMs
    Firmware allows for customization and introduction of unique features, although the security implications need meticulous consideration.
  6. 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.
  7. Special Processor Mode Support (SMM/TrustZone)
    Special modes like System Management Mode (SMM) or ARM TrustZone introduce isolated execution environments, enhancing security.
  8. Binary Blobs or Source Modules
    Firmware may include unchanged binary blobs or source modules from third-party vendors, potentially introducing vulnerabilities.
  9. IFV/IBV Added Value Customizations
    Features added by Independent Firmware Vendors (IFVs/IBVs).
  10. 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.

Figure 2 – The general Firmware Supply Chain

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.


  • Dick Wilkins

    Richard is responsible for Phoenix’s relationship with international standards groups. He joined Phoenix in 2010. He is a UEFI board member and participates in numerous security-related working groups. Richard has over 30 years of security, firmware and OS experience with organizations including HP, Microsoft, Amazon and Digital Equipment Corp. He holds a MS in Computer Science from the National Technological University and a PhD from Nova Southeastern University.

    View all posts

You May Also Like to Read

Firmware Protection: How to Solve for Firmware Security Gaps

Device and chip makers have an obligation to improve their firmware protection to defend against threats. If nothing else, they need to defend themselves. Selling products that are later revealed to have vulnerabilities is expensive and bad for the company’s reputation. Therefore, instead of taking a reactive approach, original equipment

Read More »

Firmware Security in the Age of Edge Computing

When it comes to cybersecurity, malicious attackers will always discover the weakest point in a target’s defenses and focus their attacks on that area. As each area of cyber defense grows stronger, attackers move on to the next most vulnerable component. Operating systems, applications, and networks have been significantly hardened

Read More »