In a quick journey around firmware cultures in this posting, I'll talk a bit about the recent Open Source Firmware Conference (OSFC) 2020.
The Open Source Firmware Conference (OSFC) started in 2018. It was a broadening of the coreboot conference to include other open source firmware projects. Some examples of the earlier coreboot conference include the 2016 https://www.coreboot.org/Coreboot_conference_San_Francisco_2016 where Intel talked about the ‘then recent’ UEFI Payload project https://youtu.be/I08NHJLu6Us and Intel FSP 2.0 https://youtu.be/uzfiTiP9dEM. I was invited to give the keynote of the inaugural OSFC conference in 2018 https://2018.osfc.io/uploads/talk/paper/1/OSFC_Keynote-005.pdf There common themes such as chipsec, Slim Bootloader, Min Platform, coreboot, and Intel FSP were noted.
Now have FSP SDK https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 mentioned in that keynote, too.
Fast forward to OSFC 2020 https://cfp.osfc.io/osfc2020/schedule/ and you see many of the same sentiments being reiterated. Intel talked about extending Intel FSP for programmable service engine support https://cfp.osfc.io/osfc2020/talk/TNTFYV/, a more modern configuration mechanism https://cfp.osfc.io/osfc2020/talk/AS7EZR/, and the efforts https://cfp.osfc.io/osfc2020/talk/VUNDSC/ to have a more reusable payload https://github.com/universalpayload. From those talks we then go to the efforts to remove dependencies upon SMM, including the Platform Resource Monitor (PRM) https://cfp.osfc.io/osfc2020/talk/MCJASB/.
Beyond those talks, Jiewen Yao co-presented on the Security Protocol and Data Model (SPDM) https://cfp.osfc.io/osfc2020/talk/ECQ88N/ along with Xiaoyu Ruan. SPDM is a new standard from the DMTF for device and host firmware security that is critical for upcoming security initiative support. openspdm is a sample implementation of SPDM specification. It will be used in multiple device and host firmware implementations including UEFI EDK II and possibly other platform firmware, such as a Baseboard Management Controller (BMC) based upon OpenBmc, etc.
Beyond SPDM, Jiewen also shared the background and efforts with Virtual Firmware for Intel Trust Domain Extensions (TDX) https://cfp.osfc.io/osfc2020/talk/CRKZB8/. This effort entails open source efforts to help scale enabling for TDX and provides a venue to discuss aligning enabling with other confidential computing efforts like AMD Secure Encrypted Virtualization (SEV). The TdShim is also used as a foundation for any service Trust Domain (TD) for TDX advanced feature in an EFI-light environment, such as the virtual firmware for a container or virtual TPM services. It bridges the gap between TD startup and applications running, and it enables the customers building their own use cases on top Intel TDX.
Andy Jassy during re:invent this year also spoke about how change in large companies is often driven by outsiders since long-time employees are often reluctant to replace what they've built in the past. And in the spirit of change, Rust was a topic of a few https://osfc.io/ talks this year, including the virtual hallway track discussion.
Specifically Jiewen Yao and I presented on Enabling Rust in UEFI firmware https://cfp.osfc.io/osfc2020/talk/SLFJTN/. This is a complementary talk to those by Google on enabling Rust in oreboot https://cfp.osfc.io/osfc2020/talk/SLFJTN/ and Rome https://cfp.osfc.io/osfc2020/talk/TBSHA8/, respectively. Although these are early days, there is definitely a groundswell of interest to evolve how critical infrastructure code such as firmware is written, especially given the needs for more robust code and efficiency of the developer workflow. And as an example of that sentiment, since OSFC is a virtual conference, the closest thing to the ‘hallway track’ was commentary in the sharing tool, including the following exchange on Rust
Open Source Firmware Conference 2020
In addition to that hallway track discussion above, there were other hallway discussions in the Facebook session about UEFI versus coreboot complexity.This reminded me of the culture of UEFI and coreboot, or as I sometimes think, a "windows-bios" versus a "linuxbios." By that I mean the EDK code is written in the style of Windows kernel code and coreboot is written in the style of Linux kernel code.
To begin, coreboot literally started as "LinuxBIOS", as mentioned in chapter 4 of https://www.amazon.com/gp/product/B01JC1LDTY/. EDKII history is described in the "Beyond BIOS" article https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf.
The reality of the latter is that Ken Reneris, mentioned in http://vzimmer.blogspot.com/2018/10/ghosts-of.html, created the original IBI/EFI core. He was a OS/2 and Windows kernel/Hal veteran who joined Intel in '98 around the time of the initial IBI effort. Ken brought along the same Camel Case coding style as Windows kernel code, the Containing Record (CR) https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/8_private_context_data_structures/81_containing_record_macro macro from ntddk.h into efi.h, TPL's from Windows IRQL's, .inf's, and the build command-driven build of the original EFI sample which became the EFI Developer Kit's I and II. CR's are pretty interesting in that it allows for a 'public' interface in a structure to have some appended, implementation-specific instance 'private' information. This allows for C++ keyword functionality for public/private to be emulated in C code.
Speaking of the legacy of ex-MS Ken, the prevalent use of GUID's in EFI, along with the 'protocols', or GUID-named API's, bear not a small resemblance to COM https://en.wikipedia.org/wiki/Component_Object_Model. Think iUnknown versus HandleProtocol, etc. but forging COM's C++ infrastructure in C.
Ron, on the other hand, notes that the original LinuxBIOS was derived from Linux, thus it has stutter-case/Indian Hill https://www2.cs.arizona.edu/~mccann/cstyle.html coding standard, basic make support, and Kconfig as LinuxBIOS became coreboot. coreboot also started out as fully-open, whereas EDKII slowly released more sources of the last 20 years.
Beyond coding standards, the EDK-based implementations of UEFI always vied to cover the entire boot flow, from the tuple of {reset, silicon init, platform init, OS bootload phase} as {SEC, PEI, early DXE, late DXE}. DXE is both platform initialization and the UEFI core. coreboot, on the other hand, supports the same tuple as {bootblock, romstage, ramstage, payload}. The payload for coreboot could always have been a full kernel, as CSM-like compatibility module like Seabios, or today even a EDKII-Dxe implementation in the core of the UefiPayloadPkg.
The richness of the OS bootload phase in coreboot is separated from the basic silicon and board initialization. With the DXE phase doing both platform initialization and OS bootload, the complexity of the latter ends up encroached on the former. The OS bootload code is highly reused and rich, per the UEFI specification, whereas board initialization is a high traffic area where board specific changes often occur and is the venue to host a lot of the bring-up and debug experiences.
Popping up from my trip down memory lane, OSFC also had debates between MS and others on the chat channel about the distinction between the general purpose platform where the OS producer may be different from the platform producer, versus a more vertical platform with the firmware and OS provisioned under the same authority.
Or the distinction between a full feature platform that supports a plurality of shrinkwrap OS's versus doing the minimum and letting the OS do the rest.
Another big distinction between the two is that EDK grew up initially closed and any of the open elements were released under a permissive BSD license. whereas coreboot grew up open with the GPL license. I was curious about the value of the GPL in firmware and received the following comment from Marc Jones many years ago via the question 'why hoard SATA bug fixes?' EDK BSD allows for snapping the open source instance and not redistributing changes, such as bug fixes, whereas the GPL of coreboot, Linux, and u-boot obligate the party changing the GPL code to redistribute their fixes.
Luckily, there are more than a few common points of alignment between EDKII and coreboot today. These include EDKII-based UEFI Payload Package for shrinkwrap OS support, both communities are pursuing unit tests w/ cmocka, ACPI is the predominate runtime interface, etc.
From those present-day alignments there are also some similar trends, such as the oreboot from C-based coreboot and the RUST-on-edkII investigation versus full EDKII C code
Speaking of EDKII implementations, in addition to the PDF of some of the OSFC talks, the videos of talks for OSFC 2020 can be found at https://vimeo.com/showcase/osfc-2020.
Beyond the OSFC talks, one can find the recently-published "Understanding the Trusted Boot Chain Implementation" at the following links https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/, https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.pdf, https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.mobi, and https://tianocore-docs.github.io/edk2-TrustedBootChain/release-1.00/edk2-TrustedBootChain-release-1.00.epub. These binaries are compiled from https://github.com/tianocore-docs/edk2-TrustedBootChain. This material is above-and-beyond the recent book https://www.amazon.com/Building-Secure-Firmware-Armoring-Foundation-dp-1484261054/dp/1484261054/ and was created in order to provide guidance to communities, such as the Trusted Computing Group and TianoCore, on consuming and producing the measurements in a more interoperable fashion.
I also just noticed another security related EDKII publication, namely an insightful analysis of PE/COFF image loading https://arxiv.org/pdf/2012.05471.pdf. This is close to home for UEFI and EDKII. The work reminds me of the more generic studies like https://eprint.iacr.org/2019/564.pdf.As you may have guessed from my earlier blogs and writings, I'm a fan of more formality and rigor in the pursuit of future-looking designs and validation, respectively.
