Open Source Firmware Conference 2021

This talk will be about u-bmc, a proof of concept project born out of the idea of having u-root on the BMC side as well. I will talk about the basic structure of the software stack, the way u-root and gobusybox can assemble a complete userspace that lives in a single binary, the advantages it has over OpenBMC as well as the disadvantages. In addition concepts like IPMI will be compared to gRPC which is used by u-bmc. A very short part of the presentation will also be held about u-bmc's buildsystem called Taskfile as it fits will within the topic. The current state of development and a roadmap will also be presented. This includes possible directions this project can take and also shows the progress it made in the past and how it shifted from using U-Boot to using LinuxBoot and how it could be slimmed down further using other Open Source projects that focus on barematel boot logic of ARM SoCs.

MicroPython as a full Python compiler and runtime that runs on the bare-metal, presents very light weight use cases of executable scripts for microcontrollers and embedded devices today. It is useful and beneficiary because python script can be executed without having a fully running operating system such as Linux/Windows. This presentation talks about some work done in enabling MicroPython in Coreboot with libpayload, and some potential future use case enabling that can comes with it. The platform that was used for this enabling activity is x86 QEMU. Currently coreboot limits the update of certain FSP related boot parameters during compile time only. This limits developers/advanced user to make changes rapidly. Idea here is to have Micropython based UI which allows user to modify boot parameters without having to re-compile the code. Micropython can be run as alternative payload so it doesn't hinder current user experience but can provide useful tool to developers to tinker multiple parameters without re-compiling code multiple times.

Over the last year we've grown the LVFS ecosystem over 100%. Recently we hit 2 million firmware downloads per month for the first time. There are now over 3000 firmware files available on the LVFS, with over 100 vendors using 50 different protocols. We're clearly winning. I wanted a chance to talk about the latest things that you can do on the LVFS and with fwupd. * We have more vendors using HSI for real use cases * We now have a complete Redfish implementation working with tier-1 OEM hardware. * Signed LVFS firmware reports for hardware certification. * Scanning EFI binaries on upload for common security problems. * Soft requirements in the form of recommends and requires. * A global progressbar, to be used for instance in something like ChromeOS. * Bidirectional support for VINCE, allowing us to work effectively with CERT. * Mirroring to IPFS for firmware updates from behind less-than-great firewalls. * Adding support for CapsuleOnDisk and chainloading from grub, and more generally FreeBSD. Time will be left for some questions and feedback.

### Advancing from CLIs to GUIs This talk presents the birth of [Fiedka](https://fiedka.app/) out of _utk-web_, a proof of concept image exploration tool that runs on web platforms using WebAssembly. Leveraging [Fiano](https://github.com/linuxboot/fiano)'s `utk`, Fiedka supports firmware developers and analysts through quick navigation and ideas from the web development world, organizing the many different views on the same image in a concise manner. For example, when looking at a typical AMD platform OEM image, there are UEFI and PSP parts. Walking through the challenges of building a suitable graphical interface with a great experience and dealing with specifics, the talk concludes with where Fiedka is at right now and what the next milestones will be, what users can do and try out already, and how to contribute on the various layers of back-end and front-end work as well as conceptual ideas and feature requests.

In this talk we will introduce roles for describing participation in verifiable systems, and use this terminology to understand what it means for a system to be transparent. Having a common model for these ecosystems allows for precise communication, and avoids blindly copying design decisions from other systems that may not be appropriate. By the end of this talk you will be familiar with the Claimant, Believer, Verifier, and Arbiter roles. You will understand what a Claim is, and how this is committed to by a Statement. You will understand how logs can be used to make these Statements discoverable to Verifiers, and how this can enable systems to operate using Trust But Verify. We will use Certificate Authorities and Certificate Transparency as case studies. Prior knowledge of this would be beneficial but is not required. Martin is a SWE on the TrustFabric team at Google. The TrustFabric team works on Trillian, Certificate Transparency, and also research into other verifiable data structures, witnessing, and more.

The Open-Source Firmware Foundation has been founded 6 month ago - we like to look back on the founding process, and like to invite guest to talk about workstreams within the OSFF, and the future of open-source firmware. Confirmed Guests: * Philipp and Chris summarize the past year, trying to bring the foundation to live and solving problems along the way. * Alex Matrosov is one of the first individuals leading the security workstream within the Open-Source Firmware Foundation * Bryan Cantrill, Co-Founder of Oxide, refers about open-source firmware and the rising importance of OSF within the industry * and some more.. Join in on 45 minutes of "behind the scenes" of the OSFF and general talks on why OSF is important. We will shim some light on these topics from an industry point-of-view. This session will be moderated by 9elements which will guide you through the discussion.

On Hubris and Humility: when "write your own OS" isn't the worst idea Hubris is a small open-source operating system for deeply-embedded computer systems, such as our server's replacement for the Baseboard Management Controller. Because our BMC replacement uses a lower-complexity microcontroller with region-based memory protection instead of virtual memory, our options were limited. We were unable to find an off-the-shelf option that met our requirements around safety, security, and correctness, so we wrote one. Hubris provides preemptive multitasking, memory isolation between separately-compiled components, the ability to isolate crashing drivers and restart them without affecting the rest of the system, and flexible inter-component messaging that eliminates the need for most syscalls -- in about 2000 lines of Rust. The Hubris debugger, Humility, allows us to walk up to a running system and inspect the interaction of all tasks, or capture a dump for offline debugging. However, Hubris may be more interesting for what it _doesn't_ have. There are no operations for creating or destroying tasks at runtime, no dynamic resource allocation, no driver code running in privileged mode, and no C code in the system. This removes, by construction, a lot of the attack surface normally present in similar systems. This talk will provide an overview of Hubris's design, the structure of a Hubris application, and some highlights of things we learned along the way.

Together with Daniel Smith, TrenchBoot Project Leader, we invite Open Source Firmware Community to discuss various approaches to establishing a root of trust and maintaining its security properties over platform runtime. Initial measurement is crucial to platform security because the code that creates root measurement has to be secured. S-RTM (Static Root of Trust for Measurement) is found at a fixed point in time, which is the beginning of the boot process for most platforms. Typically, it is done by Intel Boot Guard, AMD Hardware Validated Boot, NXP High-Assured Boot, or other proprietary implementations. S-RTM-related measurements are recorded in TPM PCR[0-7]. Those can be used for local attestation (unsealing of secret, e.g., disk encryption password) or remote attestation. Finally, to keep the security properties of S-RTM, there is a need for a mechanism that can adjust firmware measurements after its update. D-RTM (Dynamic Root of Trust for Measurement) can be established at any point in time through dedicated hardware and firmware functions. D-RTM initial measurement happens right before the execution of minimal code called D-RTM Configuration Environment, which establishes a new Root of Trust for Measurement. D-RTM-related measurements are recorded in PCR[17-22] protected by hardware through the TPM locality mechanism. Obtained measurements can be used in precisely the same way as in the S-RTM case. Let's discuss: - update mechanisms - protection mechanisms for S-RTM and D-RTM - future of related functionality - synergy: beyond RTM coexistence

oreboot is a derivative of coreboot without C. The oreboot is a fully open-source power-on-reset and romstage firmware written in Rust. oreboot can boot the following: * Linux on Sifive Unleashed with M-Mode kernel * Linux on Beagle-V * Linux on x86 QEMU with Intel FSP * Linux on RISC-V QEMU * Linux on arm QEMU Currently being brought up on: * AMD Picasso-based Chromebooks * AMD Rome on AMD Reference Board * UPXtreme with Intel Coffeelake FSP There have been some slight adjustments to oreboot's firmware driver models. Each driver is distilled into basic functions including: init, pread, pwrite, ctl, and status. The ctl and status are new. This interface allows us to make convenient higher-level drivers such as a "union driver" which duplicates a single write operation to multiple drivers. This makes consoles which have multiple underlying UART drivers elegant. The oreboot driver model inspired recent changes to the coreboot console code, within the limits of what C will allow of course. By using the Rust programming language, oreboot has a leg-up in terms of security and reliability compared to contemporary firmware written in C or assembly. Rust's borrow-checker ensures pointers are not used after freed and proves that coroutines are thread-safe at compile time. We know the stack size at compile time. There is no need for linker sets. We have the appearance of dynamically sized vectors without needing an allocator. There is no heap. Macros are safe. Rust optimizations far exceed what is possible in coreboot.

Nowadays, it’s difficult to find any hardware vendor who develops all the components present in its products. Many of these components, including firmware, are outsourced to ODMs. As a result, this limits the ability of hardware vendors to have complete control over their hardware products. In addition to creating extra supply chain security risks, this also produces security gaps in the threat modeling process. Through this research, ​we wanted to raise awareness about the risks in the firmware supply chain and the complexity of fixing known vulnerabilities. The firmware patch cycles last typically around 6-9 months (sometimes even longer) due to the complexity of the firmware supply chain and the lack of a uniform patching process. The 1-day and n-day vulnerabilities in many cases have a large impact on enterprises since the latest firmware update wasn’t installed or the device vendor had not released a patch yet. Each vendor follows their own patch cycle. Even known issues may not be patched until the next firmware update is available. We decided to build an open-source framework to identify known vulnerabilities in the context of UEFI specifics, classify them based on their impact and detect across the firmware ecosystem with the help of the LVFS project. We will be sharing our approach as well as the tooling we have created to help industry identify the problems and get patched.

Assuring platform integrity is top-of-mind for platform owners. Hardware roots of trust can measure and attest to firmware integrity, but this is only one component of platform integrity in hyperscalar environments, which impose a number of practical design constraints. Constraints include scaling to a large fleet of machines, scaling to increasingly complex machines, and all while ensuring the high levels of availability and reliability required of our data center fleet. This talk gives an overview of a platform attestation framework designed by Google, whose primary goals consist of providing scalable recovery from firmware vulnerabilities, while amortizing engineering effort across multiple hardware devices and configurations. Subjects of interest include: * Attestation policy content, generation, revocation, and enforcement. * Representing the physical model of complex platform topologies. * Contributions Google has made to standards like SPDM and Redfish, to enable platform operators to directly verify attestations from a wide range of roots of trust.

Modern Arm machines have management processors, security states, and EL3 (which is conceptually somewhat similar to SMM on x86). They also have a wild west of power, clock, and nonstandard hardware devices which need to be supported before general purpose operating systems can be utilized. In the server space, Arm has hardware (SBSA) and firmware (SBBR) standards for assuring long term support, as well as providing a "just works" experience for end users. The Arm SystemReady program is designed to bring many of these advantages to the Edge and Iot markets as well. It is born out of the fact that much of the what makes x86 or SBSA/SBBR work are standardized firmware abstractions that create a common platform out of diverse hardware, and questioning what the minimal HW platform that is required for those software standards to work. A couple years ago, the RPi was identified as an easily available platform that could be used to demonstrate that it was possible to boot a wide range of OS's without a lot of custom driver/etc work by focusing on the firmware. Earlier this year the resulting community first, opensource project (https://github.com/pftf/), was successfully one of the first platforms to be SystemReady ES certified and boots a who's who of OSs and hypervisors, both opensource and commercial. This talk will focus on explaining some of what modern Arm machines look like, their failings, how much code we avoided putting in the Linux kernel, as well as some concrete examples of platform abstraction in ACPI/AML in the context of the RPi. It will also cover some of the critical HW/SW problems that can stop a project like this from succeeding.

Taking advantage of Secure Boot should be simple! But convoluted tooling and poor documentation makes this extremely hard for people to navigate viable options, opting them to disable Secure Boot unless they are using the shim provided by larger distributions. In this talk I'll introduce the tooling improvements I have made in this space. go-uefi which is a userspace library for dealing with efivarfs with high-level abstractions and support for the most common operations towards secure boot on Linux. Built on-top of this is the secure boot key manager, sbctl. This aims to be a user-friendly way of setting up and interacting with secure boot for the common user. We will take a look at why secure boot is hard to grasp for users, the current challenges facing the existing tools and how sbctl solves these. Lastly, we will introduce some solutions to deal with the largest hurdle that stands in the way of independent key management: Option ROM.

The Base Boot Requirements (BBR) specification defines standard firmware interfaces for OS and Hypervisors boot on Arm 64-bit based systems. It builds on Arm’s standards-based approach for systems design. The BBR specification defines multiple “recipes” to accommodate different requirements across various operating systems and use cases, regardless of the segments. The LBBR recipe is defined specifically for Arm servers using LinuxBoot based firmware. LinuxBoot (https://www.linuxboot.org/) is an open-source project to replace certain UEFI stages with a Linux kernel and runtime. The LBBR recipe is created to address the needs of hyperscalers and CSPs, where LinuxBoot is often a business requirement. In this presentation, we will highlight the latest developments in defining the LBBR recipe, and show how LinuxBoot can be implemented on Arm systems to be compliant with the requirements. We will also explain how the LBBR recipe is used to build SystemReady LS compliant servers. Finally, we will demonstrate open source proof of concept implementations of LBBR compatible firmware on different devices.

In this talk, I will talk about coreboot/LinuxBoot development progress on OCP Delta Lake, which is a single-socket compute server based on the 3rd Gen Intel Xeon Scalable processor Cooper Lake. This is a joint effort between Wiwynn, Facebook, Intel and 9elements. The OCP Open System Firmware project is an initiative with the goal to move the control of firmware to the system owner. It allows the system firmware (also known as BIOS) to be modified and shared openly. Starting from March 2021, “OCP Accepted” badge for servers requires that server systems support OSF and can pass the OSF checklist. Delta Lake is the first server product that achieves this milestone. I will present the development progress, how to download and build the firmware image, and the OCP OSF checklist. Our firmware configuration method is also presented. And finally, I will share the benefits of employing an open source firmware solution for our customers.

Nowadays, it’s difficult to find any hardware vendor who develops all the components present in its products. Many of these components, including firmware, are outsourced to ODMs. As a result, this limits the ability of hardware vendors to have complete control over their hardware products. In addition to creating extra supply chain security risks, this also produces security gaps in the threat modeling process. Through this research, ​we wanted to raise awareness about the risks in the firmware supply chain and the complexity of fixing known vulnerabilities. The firmware patch cycles last typically around 6-9 months (sometimes even longer) due to the complexity of the firmware supply chain and the lack of a uniform patching process. The 1-day and n-day vulnerabilities in many cases have a large impact on enterprises since the latest firmware update wasn’t installed or the device vendor had not released a patch yet. Each vendor follows their own patch cycle. Even known issues may not be patched until the next firmware update is available. We decided to build an open-source framework to identify known vulnerabilities in the context of UEFI specifics, classify them based on their impact and detect across the firmware ecosystem with the help of the LVFS project. We will be sharing our approach as well as the tooling we have created to help industry identify the problems and get patched. Workshop outline: * Why it's important to get patched in time, and why your EDR won't help you with compromised firmware? * The uefi_r2 scanner details internals (https://github.com/binarly-io/uefi_r2) * How semantic code annotations work to bring UEFI codentext for code analysis * How to scale uefi_r2 scanner in enterprise infrastructure? * Deep dive into FwHunt rules format * What is the difference between detecting new and known issues? * How does the FwHunt detection work on different layers PEI/DXE/SMM? * LVFS integration of uefi_r2 and FwHunt * How patch the industry deal with the help of LVFS? * Future plans and upcoming updates for FwHunt technology

In May 2020, initial support for unit testing the coreboot landed in the tree - it was included in the 4.12 release. During talk on the OSFC2020 we described why firmware (and especially coreboot) benefits from the unit testing and how unit testing framework in coreboot is working from the background. In almost every area of programming new frameworks aren't something stable from the beginning - the same applies for unit testing frameworks. In parallel with writing tests for new modules new challenges arise. Almost every new test brings in the need for improving the testing framework and infrastructure. Once starting this journey we weren't sure where it would end and how difficult it may be to test such low-level code as coreboot firmware. We want to go through what the community achieved during the previous year and whether all goals were reached. What is the current test coverage and how test coverage statistics reports work. Furthermore, what were the new features and improvements introduced into the unit testing framework. Finally, how the new libpayload test framework will look like and how the new mock architecture is working.

RunDXERun allows safe execution of UEFI boot applications. It runs these applications in a KVM-based VM, using a Virtual Machine Manager (VMM) written in Go. As the boot applications call UEFI services, they exit the VM and and the RunDXERun VMM handles them. The services themselves are also implemented in Go. RunDXERun is intended to be compiled as part of u-root and used in firmware images. As of October, RunDXERun successfully starts the u-boot EFItest program, and runs one of its tests. RunDXERun in a u-root image increases its size by about 500K (uncompressed) or 145K (xz compressed). This is not much larger than building in a full EDK2. It fits easily in payloads destined for coreboot. The reason to use RunDXERun is for the security it provides. Normally, UEFI boot applications run at the highest privilege level of a machine, as do the boot services. RunDXERun allows running both applications and UEFI services at the lowest privilege level, and the services are implemented in a memory safe language. RunDXERun is similar in spirit to the "safe" ROM support already in coreboot. RunDXERun compiles for both x86 and ARM64; writing the initial port for ARM64 took four hours.

This talk will cover Universal Scalable Firmware (USF). USF entails an evolution of the platform firmware stack. It entails evolutions from the hardware through the SOC to the platform layer and in the OS facing payload. Elements of the stack include the system on a chip (SOC) abstraction layer (SAL) into the scalable Firmware Support Package (sFSP). Atop of the sFSP a set of infrastructure referred to as the Platform Orchestration Layer (POL) will support a plurality of bootloader implementations, such as coreboot, EDKII, and slim bootloader. Each of these POL entities can then be composed with a Universal Payload to provide alternate boot methodologies such as UEFI and LinuxBoot. In addition to supporting a variety of POL's, this work hopes to support a variety of implementation languages beyond C, including Rust. And beyond booting, USF provides guidance on more consistent configuration using YAML and firmware support beyond the host CPU SOC into alternate platform computing elements, or XPU’s. More information on this work can be found at https://github.com/UniversalScalableFirmware.

coreboot has support for many recent Intel platforms, largely thanks to Google's commitment to open source firmware in their Chromebook line of laptops. However, despite the fact that the chips themselves are well supported, getting coreboot to run on other recent Intel based laptops can be more challenging than one might think. We will present the current state of support for the latest Intel platforms in coreboot and what it takes to get coreboot running on a recent Intel based laptop. We'll then discuss some of the largest obstacles we encountered while developing a coreboot port for one of our clients' laptops, including Windows compatibility, power management and dealing with proprietary embedded controller firmware. We will also discuss other components needed to replace proprietary firmware completely, as well as reasons why one might want to have coreboot power their newest laptop in the first place, considering the current blob situation.

It's been a long held notion that having standardized testing across the various near metal projects. With standardized testing, we can build a testing framework to test platforms that have open hardware components across coreboot, linuxboot, u-root and so on. With these in place we would be able to thoroughly test all platforms that use these ecosystems. Furthermore by agreeing on the framework we would be able to build our own internal tests for the platforms we care about. This brief talk will talk about the fundamentals of standard testing and how we can build these tests using ConTest, a testing framework that was written by Facebook and released as an open source project. By standardizing on a single framework we will be able to ramp up specific tests to help build more reliable platforms by being able to detect regressions, adding new tests for new failure scenarios and so on. We hope that after this talk that you would be excited in joining the effort to build these tests and improve the state of these open source projects and the platforms that depend on it.

The open-source Slim Bootloader project began 3 years ago with the goal of providing a boot firmware that’s specific to Internet of Things use cases especially in Intel-based embedded systems and solutions. It’s also designed to be small in flash footprint, boots fast, secure, extensible, and easily configurable. Since its inception, Slim Bootloader has matured into a robust boot firmware with multiple exciting new features such as Time Coordinated Computing (TCC) technology, Functional Safety (FuSa), Firmware Update Resiliency, enhanced firmware & Intel Firmware Support Package (FSP) configuration just to name a few. As Intel continues to release various new processors and System on Chips (SoC), the Intel team has continued to enable Slim Bootloader support for them on the respective reference platform offerings. This talk will provide a state of art update of what has changed over the years and what we’ve learnt from maintaining it in the open-source community.