Meet the UEFI Corporation!
Learning about UEFI and the UEFI corporation
(don't run scripts on webpages)(links are direct)
I'm trying to understand what UEFI is, and how it's put together, how it works, how to alter it's behavior,
and over the years I've watched new features get introduced into computers, that I didn't understand,
but always with a creeping sense of doom surrounding the systems firmware. Anyways so I sat around
following links, reading stuff, and keeping notes about it
(unique names of software/hardware manufacturers https://uefi.org/learning_center/presentationsandvideos)
(IBM) Intel, AMD, Microsoft, Google, Arm, AMI, Phoenix, Insyde, NUVIA inc.,
Eclypsium, ASSET Intertech inc. Oracle, Facebook, Canonical Group Ltd., American Megatrends inc.,
Linaro, Flex Institute of Technology, HPE, NXP,
UEFI Forum
https://en.wikipedia.org/wiki/UEFI_Forum
UEFI Forum, Inc. is an alliance between technology companies to coordinate the development of the UEFI specifications. The board of directors includes representatives from twelve promoter companies: AMD, American Megatrends, ARM, Apple, Dell, Hewlett Packard Enterprise, HP Inc., Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies.
The non-profit corporation has assumed responsibility for the management and promotion of the Unified Extensible Firmware Interface (UEFI) specification, a bootloader and runtime interface between platform firmware and an operating system. The original EFI specification was developed by Intel and was used as the starting point from which the UEFI versions were developed. The goal of the organization is to replace the aging PC BIOS.
In addition to the UEFI specification, the forum is responsible for a UEFI Platform Initialization (PI) specification, which addresses the firmware internal architecture as well as firmware-to-hardware interfaces. The forum also is responsible for Self-Certification Test suites, which defines conformance to the specifications that it defines.
In October 2013, the Advanced Configuration and Power Interface (ACPI) assets have also been transferred into the forum.[1] The forum is responsible for the management and promotion of future ACPI specifications, which provides static tables at boot time and dynamic control methods as the primary runtime interfaces between the OS and system firmware for system configuration, power management and RAS (Reliability, Availability and Supportability) features. ACPI "Revision 5.0"[2] is used as the starting point from which future ACPI versions will be developed.
Published specifications
UEFI Specification version 2.8, published March, 2019
UEFI Shell Specification version 2.2, published January 26, 2016
UEFI Platform Initialization Specification version 1.7, published January, 2019
UEFI Platform Initialization Distribution Packaging Specification version 1.1, published January, 2016
ACPI Specification version 6.4, published January 2021
https://uefi.org/blog/understanding-uefi-and-firmware-ecosystem
Understanding UEFI and the Firmware Ecosystem
Blog Author
UEFI Forum
February 25, 2020
To understand how system firmware is generated for modern computer systems, it is important to first understand the ecosystem and commonly used terminology. This post helps readers gain a better understanding of the development process, the industry’s “unique language” and how it applies to UEFI firmware.
An Original Design Manufacturer (ODM), such as Quanta, Foxconn or Compal, develops hardware on behalf of an Original Equipment Manufacturer (OEM) like Dell, HP or Lenovo. The system purchased by an end-user needs properly developed system firmware to boot and initialize the system. UEFI established a standard used by ODMs and OEMs ensuring compatibility with major operating systems, peripheral hardware and third-party software.
ODMs and OEMs have their own firmware teams, creating a firmware image tailored to each platform’s hardware configuration. The teams can create their own custom solution, but often they license a UEFI development codebase from an Independent Firmware Vendor (IFV) like AMI, Byosoft, Insyde Software or Phoenix Technologies. IFV solutions are based on reference designs from silicon manufacturers, which the ODM and OEM use as the basis for end-user products.
To illustrate the role of UEFI Specifications in the ecosystem, consider the following scenario:
An OEM wants to develop a new laptop, so it contracts an ODM to build a laptop based on silicon reference design.
The IFV partnered with the ODM provides a generic kit that enables the silicon vendor’s reference design platform.
The ODM customizes the system firmware to initialize the laptop to the OEM specification. As a result, the firmware is specifically designed for that OEM’s platform.
The final UEFI firmware image is a result of cooperation between OEM, ODM and IFV.
Despite the customization, each part of the ecosystem designs the firmware to meet UEFI Forum specifications, so it is compatible with off-the shelf software and hardware. Working from standards-based firmware provides a seamless user experience.
Testing hardware interoperability is a very important phase of product development. This is when OEMs discover how the hardware and operating system work with system components. Devices essential to system booting follow UEFI Specifications to ensure firmware interoperability.
UEFI Plugfests offer a unique opportunity for testing against UEFI Specifications. Vendors from across the industry staff multiple testing rooms, providing an assortment of software and hardware for interoperability testing. Our next event – Spring 2020 UEFI Plugfest – is now open for registration. If you have questions about UEFI or the upcoming event, please contact us at [email protected].
MICROSOFT’S CONTINUED INVESTMENTS IN THE UEFI ECOSYSTEM: YOUR UNANSWERED QUESTIONS, ANSWERED
Blog Author
Bret Barkelew, Matthew Carlson and Jeremiah Cox (Microsoft)
August 25, 2020
UEFI Forum members from Microsoft recently presented a webinar as part of the UEFI 2020 Virtual Plugfest series titled “Microsoft’s Continued Advancements in the UEFI Ecosystem.” The presentation covered open source tools and open source integration, explored their “Code First” model and much more. View the recorded presentation and the webinar slides for additional information about Microsoft’s history of contributions to the UEFI ecosystem and plans for future advancements.
The following questions were asked by attendees during the live webinar and answered by technology experts from Microsoft.
Q: Microsoft is continuing to invest heavily in UEFI technology. Can you speak more to your UEFI plans moving forward?
A: Microsoft will continue investing in both improving the developer experience and open source implementations. We are finding success in this implementation-first model and plan to continue down that path while we continue collaboration on the UEFI specifications.
Q: What do you consider a host-based unit test?
A: Tests that execute on a host rather than a target. Like some other C-based testing frameworks, instead of building a large ROM and putting it on a target system, you are building portions of that business logic into an executable that can execute on your development system. It can be built into a native binary for the build system and executed as part of continuous integration. The test cases will dispatch, ensuring a fantastic debuggable environment to test that all possible parameters being passed into this routine are covered. Additionally, this approach makes it easier to account for memory management. For example, by the time you make it out of this routine, any buffers that were allocated internally should be freed and no null-pointers should be consumed. The approach also provides a platform to do more robust fuzzing because once you have abstracted the interfaces to the point where you can run the unit test, you can also randomize those inputs and fuzz them. The advantages include the simplicity of running an executable, as well as gaining speed and environment flexibility. By having a host-based unit test for as many things as possible, we can run those tests on the build server or as part of a PR gate to ensure that these interfaces are upheld.
Q: Does the binary model need the reproducible build toolchain? For example, the same binary is generated from the same version source code in different development machines.
A: Yes, but it is important to verify the source of where it came from. By identifying the origin, you are ensuring that this binary comes from this commit. It is important that each binary that is distributed came from a verified build server for security assurance and that the hash that you see when the binary was published is correct. There are some changes from binary to binary, even when you compile the same one repeatedly. However, the binary overall functionality and layout should be the same every single time and be verifiable.
Q: Does the crypto in the binary model only include authentication or full encryption of the binary?
A: In our case, the binary model of crypto we implemented included all the crypto that EFI Development Kit (EDK) 2 uses, including hashing, encrypting, PKS7, X509 and a bunch of other functionalities – it’s a large surface area. If you wanted to verify a new binary, you would need to use the binary model version of crypto. For example, keep in mind that Device Firmware Configuration Interface (DFCI) and Manufacturer Firmware Configuration Interface (MFCI) brought in more modules that perform crypto and by using this binary model, we were able to achieve significant flash space savings over having multiple copies of crypto linked into different modules, even after FV compression.
Q: What is the EDK II build performance difference when using pytools vs. the original base tools?
A: The ultimate build process is executed and handed off to EDK II base tools (or arguably any underlying build system) while pytools attempts to make that environment easier to configure and reproducible. Early on, we decided to investigate a sub-module pattern – the idea that we’re going to go through and cut up the entire platform source tree and figure out which sections are common to certain behaviors, platforms or requirements – and we are going to wrap those in their repository. The borders of these repositories are not only dictated by technical requirements but often by business requirements. These boundaries were designated pools of collaboration, but more complicated, hierarchical and stratified code layout necessitated solutions. This ensured that each platform does not need massive amounts of configuration for exactly which repository or parts of the tree that it intends to use or carry, but rather specific subsets. You would like to treat the repository below you as more or less transparent when you choose to update. As a platform owner, you should be able to evaluate your code and an update should never be forced on you. When you choose to update from one release to another, all you should need to do is look at the change notes for any breaking changes and then update once you have acknowledged those breaking changes. To keep those breaking changes to a minimum, we needed a way to encapsulate the build configuration and some of the other things into each repository so that the configuration would change as the repository changed, or as the target branch or target release changed.
Ultimately, the EDK II build performance runs slightly slower while using pytools due to meta-processing on top of base tools. However, the goal is to enable you to only build what is necessary without having to granularly manage it. We want to offer flexibility so that the time saved doing the configuration becomes machine hours running builds on build servers.
Microsoft is committed to using UEFI to build a variety of devices. Pytools is for componentization and code reuse across products. Microsoft works on large-scale projects that span teams, companies and silicon providers. We build construct reusable components that can be better leveraged by pytools to make it easier to integrate into different products. This or componentization boosts our efficiency when we reuse these components across products and when we service these components across products.
Q: Are there any additional protections in the Operating System (OS) for Protected Runtime Mechanism (PRM), over what the OS already offers?
A: PRM executes in an execution and security context like UEFI Runtime Services and the Windows kernel. It improves overall system security by reducing the attack surface of System Management Mode (SMM), reducing the likelihood of an SMM vulnerability and compromise. Keeping SMM secure not only protects the firmware but also prevents “confused deputy” attacks against Windows Virtualization Based Security (VBS).
Q: Does DFCI require access to the Internet (MS.com, etc.) or can it run within a self-contained data center?
A: A reference implementation of DFCI is available on GitHub as an open source with a permissive BSD license. The provided implementation includes Microsoft URLs and certificates, assuming a connection to Microsoft services. These Microsoft services do not currently offer an offline configuration story. Although this is not a feature today, if there is a strong business justification for it, we would consider incorporating it in the future. Also, the source is open, so it would be possible for someone to add this through code modifications and by standing up their services.
Stay tuned for future presentations part of the UEFI 2020 Virtual Plugfest. Subscribe to the UEFI Forum YouTube channel and UEFI Forum BrightTALK channel to view the presentations anytime and be notified about upcoming webinars.
https://uefi.org/learning_center/presentationsandvideos
UEFI 2025 Webinar Series
May 20, 2025: Secure by Design and Zero-Trust Architectures for Firmware
Presentation Slides
https://uefi.org/sites/default/files/resources/Secure%20By%20Design%20Webinar.pdf
YouTube
https://www.youtube.com/watch?v=CSL_nQK_S7c
April 1: 2025: Firmware as a Service: Enhancing BIOS Security and Flexibility
Presentation Slides
https://uefi.org/node/5156
YouTube
https://www.youtube.com/watch?v=EQ26fwpy4OQ
BrightTALK
https://www.brighttalk.com/webcast/18206/638309?utm_source=brighttalk-portal&utm_medium=web&utm_campaign=channel-page&utm_content=recorded
February 20, 2025: EDK2-Test: New Test Coverages and Future Roadmap
Presentation Slides
https://uefi.org/sites/default/files/resources/EDK2-Test%20New%20Test%20Coverages%20and%20Future%20Roadmap_FINAL.pdf
YouTube
https://www.youtube.com/watch?v=WA9assjUXzo
BrightTALK
https://www.brighttalk.com/webcast/18206/635261?utm_source=UEFIForum&utm_medium=brighttalk&utm_campaign=635261
UEFI 2024 Webinar Series
November 21, 2024: Coordinating UEFI Vulnerabilities as CERT/CC
Presentation Slides
YouTube
BrightTALK
October 24, 2024: UEFI Unveiled: Ensuring Transparency in Your Firmware
Presentation Slides
YouTube
BrightTALK
March 13, 2024: Challenges, Solutions and Benefits of Integrating Wireless Drivers in UEFI Firmware
Presentation Slides
YouTube
BrightTALK
February 20, 2024: EDK2Code: VSCODE Extension for EDK2
Presentation Slides
YouTube
BrightTALK
UEFI Fall 2023 Developers Conference & Plugfest October 9 - 12
State of the UEFI - Mark Doran (UEFI Forum President)
https://uefi.org/sites/default/files/resources/State%20of%20UEFI_Mark%20Doran.pdf
Using SPDM in UEFI for Device Attestation - Michael Kubacki (Microsoft) and Vincent Zimmer (Intel)
UEFI Ecosystem Investments and Open-Source Contributions - Michael Kubacki (Microsoft)
Evolving the Secure Boot Ecosystem - Doug Flick and Jeffrey Sutherland (Microsoft)
Hardening the Core: Enhanced Memory Protections - Taylor Beebe (Microsoft)
https://uefi.org/sites/default/files/resources/Hardening%20the%20Core%20Enhanced%20Memory%20Protection_Beebe.pdf
Conversations on Bolstering UEFI Cybersecurity - Jonathan Spring (CISA)
https://uefi.org/sites/default/files/resources/Conversations%20on%20Bolstering%20UEFI%20Cybersecurity_Spring.pdf
UEFI Goes to Washington - Tim Lewis (Insyde)
https://uefi.org/sites/default/files/resources/UEFI%20Goes%20to%20Washington_Lewis.pdf
CVSSv4 Firmware Scoring: A Call For Collaborative Action - Dick Wilkins (Phoenix)
Vulnerability Management in UEFI - Brian Mullen (AMI)
https://uefi.org/sites/default/files/resources/Vulnerability%20Management%20in%20UEFI_Mullen.pdf
UEFI and ACPI in Arm System Architecture - Dong Wei (Arm)
Embracing Modularity and Boot-time Configuration: Faster TTM with Tiano-based Solutions - Andrei Warkentin (Intel)
UEFI Key Management Service (KMS) With TPM - Felix Polyudov and Frederick Otumfuor (AMI)
Multi-ISA Driver Compatibility: What’s the Future? - Andrei Warkentin (Intel)
Extending EDK2 Functionalities to GNU- EFI - Mikolaj Lisik (Google)
Creating an EDK2 Firmware Image With an Embedded Application - Mikolaj Lisik (Google)
Firmware Configuration – Past, Present, and Future - Vincent Zimmer (Intel)
https://uefi.org/sites/default/files/resources/Firmware%20Configuration%20%E2%80%93%20Past%2C%20Present%2C%20and%20Future_Zimmer.pdf
https://en.wikipedia.org/wiki/Software_supply_chain
Software supply chain
A software supply chain is the components, libraries, tools, and processes used to develop, build, and publish a software artifact.[1]
A software bill of materials (SBOM) declares the inventory of components used to build a software artifact, including any open source and proprietary software components.[2][3] It is the software analogue to the traditional manufacturing BOM, which is used as part of supply chain management.[4]
Usage
An SBOM allows builders to make sure open-source and third-party software components are up to date and respond quickly to new vulnerabilities.[5] Buyers and other stakeholders can use an SBOM to perform vulnerability or license analysis, which can be used to evaluate and manage risk in a product.[6][7][8]
While many companies use a spreadsheet for general BOM management, there are additional risks and issues in an SBOM written to a spreadsheet. It is best practice for SBOMs to be collectively stored in a repository that can be part of other automation systems and easily queried by other applications.[citation needed]
Legislation
The Cyber Supply Chain Management and Transparency Act of 2014[9] was a failed piece of US legislation (bill) that proposed to require government agencies to obtain SBOMs for any new products they purchase and to obtain SBOMs for "any software, firmware, or product in use by the United States Government". The act spurred later legislation such as "Internet of Things Cybersecurity Improvement Act of 2017."[10][11]
US President Joe Biden’s Executive Order 14028 on Improving the Nation’s Cybersecurity of May 12, 2021 ordered NIST and NTIA to lay down guidelines for software supply chain management, including for SBOMs.[12] The NTIA outlines three broad categories of minimum elements of SBOMs: data fields (baseline information about each software component), automation support (the ability to generate SBOMs in machine- and human-readable formats), and practices and processes (how and when organizations should generate SBOMs).[13] The "automation support" requirement specifies the need for "automatic generation," which is possible with the use of Software Composition Analysis (SCA) solutions.[14]
found one of my key words mentioned on gnu.org under the page for proprietary backdoors, how do we prevent this behavior?
https://www.gnu.org/proprietary/proprietary-back-doors.html
" 2023-06
Eclypsium discovered an insecure universal back door on many computers using Gigabyte mainboards. Gigabyte designed their nonfree firmware so they could add a program to Windows to download additional software from the Internet, and run it behind the user's back.
To add injury to injury, the back-door program was insecure, and opened ways for crackers to run their own programs on the affected systems, also behind the user's back. Gigabyte's “solution” was to ensure the back door would only run programs from Gigabyte.
In this case, the back door required the connivance of Windows accepting the program, and running it behind the user's back. Free operating systems rightly ignore such “Greek gifts,” so users of GNU (including GNU/Linux) are safe from this particular back door, even on affected hardware.
Nonfree software does not make your computer secure—it does the opposite: it prevents you from trying to secure it. When nonfree programs are required for booting and impossible to replace, they are, in effect, a low-level rootkit. All the things that the industry has done to make its power over you secure against you also protect firmware-level rootkits against you.
Instead of allowing Intel, AMD, Apple and perhaps ARM to impose security through tyranny, we should demand laws that require them to allow users to install their choice of startup software and make available the information needed to develop such. Think of this as right-to-repair at the initialization stage.
Note: Eclypsium at least mentions the problem of “unwanted behavior within official firmware,” but does not seem to recognize that the only real solution is for firmware to be free, so users can fix these problems without having to rely on the vendor."
(I have a computer like that xD)