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.