Operating bare-metal servers implies running closed-source firmware. While hyperscalers operate open-source firmware in production for years, smaller companies consider this revolution to be out unattainable.

Criteo faces daily operational issues with its 40K+ servers infrastructure that could be solved or improved by running open-source firmware. To ease this transition, Criteo collaborates with HPE to use open firmware on regular 19" servers.

Using real production issues and how they could be solved or avoided in an open world, this talk will describe why this transition is a major step toward a more secure, flexible, and maintainable infrastructure.

VBE supports firmware update, OS selection and other features that traditionally rely on the UEFI standard. It is simpler, more deterministic and easier to extend and test.

VBE comprises an implementation in U-Boot (using the new standard boot), firmware update in fwupd. It is designed to support verified boot (where SDRAM-init code and most firmware can be updated).

VBE is designed with embedded systems in mind. Rather than ignoring the existing boot methods and trying to shoe-horn UEFI into embedded systems, VBE extends the existing methods, such as U-Boot's Flat Image Tree.

This talk introduces the concept and the capability. It discusses the trade-offs that have been made and ends with a demo on an ARM board.

Since the origin of the system firmware, it’s always remained closed-source and only nourished by a closed group knowing it might not be interesting for a larger audience. Over the last decade the movement around freedom in software development also touches the core of the firmware and open-source community demands even more openness in system firmware development. System firmware which is running at the most privileged level than any Ring 0 software (may be refer it as, Ring -1 or Ring -2 where CSE or PSP is running and lots of direct access to the hardware registers, sideband access etc.) is now demanding more openness.

In the last decade of open-source firmware (OSF) development, the community has experienced the support from most of the Silicon and Hardware vendors to ensure system firmware development using open-source projects like coreboot (as an example). But the fundamental problem that has been ignored so far is the invisible control of the silicon vendors in this entire system firmware development activity in terms of silicon reference code which has deployed as closed source binaries. coreboot, like any other OSF project, doesn't have any way to escape from its dependency. Additionally, open-source community members can’t contribute (honestly no visibility) to the silicon reference code. Hence, this talk is going to walk you through the “Thing” (a.k.a silicon reference code and associated firmware code running on your embedded device) that is around your system firmware and finally controls your free movement.

Outline:
* Current situation in OSF
* Problem statement
* Working towards standardizing how to handle silicon code in OSF
* One path towards more open-source in firmware
* Case Study: FSP-S Reduction in coreboot
* Outlook

TPM interactions over a physical bus (SPI, I2C, etc) can currently be protected against passive interposers with TPM sessions. However, this mechanism is vulnerable to attacks which can send/modify/drop packets going over the TPM bus.

As server designs in data centers become more modular, these types of attacks become increasingly simple for an attacker to pull off. With less than $30 of equipment, TPMs on modern servers can be compromised via bus interposer attacks. This talk will introduce the different variants of this style of attack and why you should care.

Additionally, we will look at how we can use a DICE-as-a-Service API in the CPU to bootstrap protocols to protect this channel in a way that can be verified by remote attesters.

In the industry, speculative execution mitigations have been discussed for some time, but most people focus on the operating system level in order to adopt them in software stacks. What is happening at firmware level? When it comes to applying mitigations, how does the industry take advantage of them, and who controls their adoption in the firmware? Those are all good questions, but unfortunately no positive news can be shared. SMM attack vectors will be discussed in this talk from the perspective of attacking the operating system or hypervisor from the firmware. The nature of these attacks breaks the foundation of confidential computing and often creates problems for the entire industry. This talk will focus on practical examples of such attacks and how they are dangerous.

Historically, proprietary systems created the need for binary machine interfaces. This extended to the deepest layers of the system, where the PC BIOS was created to make machines look sufficiently identical to one another that an opaque blob -- the operating system -- could run on them. We enshrined these sedimented layers as "firmware", but in fact there is no such thing: this is merely proprietary, opaque software by another name.

The approach that we're taking at Oxide is radically different: instead of merely relying on marginally better implementations of dated abstractions, we are eliminating the abstractions entirely. Rather than have one operating system that boots another that boots another, we have returned the operating system to its roots as the software that abstracts the hardware: we execute a single, holistic system from first instruction to running user-level application code. This has, of course, been technically challenging, as it has required us to incorporate the lowest levels of machine initialization. But that our small team has prevailed also shows its viability: this is delicate, but it isn't impossible -- and indeed, having been to the mountaintop, we believe that not only is the holistic artifact more robust, the path was in fact faster than relying on a proprietary initialization layer.

In this talk, we will discuss our holistic approach: why we have taken it, the challenges that we faced, why we believe that this approach is increasingly viable in an all-open world -- and what we need out of CPU vendors to support such systems.

As strange as it first seems, chainloading Windows from Linux might be the more secure way to boot the system. From within a minimal PXE booted runtime, the Linux shell scripts can perform a TPM-rooted remote attestation with the normal tpm2 tools, receive the BitLocker keys from the attestation server using the safeboot scripts and safely pass them to Microsoft’s bootloader in a UEFI ramdisk via a form of kexec. This specialized Linux kernel and initrd also makes an ideal OS install and recovery environment since it can use the vendor-provided UEFI device drivers to talk to the hardware, allowing a generic kernel to work on most devices without customization.

LinuxBoot is now widely deployed, by many companies, on millions of systems, in data centers around the world. LinuxBoot was started, in 2017, by intent, as a UEFI project. To put it more strongly, in the beginning, we explicitly rejected coreboot integration as a primary, secondary, or even tertiary goal.
The entire thrust of LinuxBoot was to greatly reduce the size of UEFI, and hence the large attack surface UEFI represented, and replace most of UEFI with Linux. But we never intended to replace all of UEFI: we had no desire to re-argue the UEFI vs. coreboot debate, and, indeed, saw no prospect of ever resuming use of coreboot on x86 servers.

The world is full of surprises. Once companies began to realize how little of UEFI they needed, they began to ask how to remove it completely. As chance would have it, Meta and Intel had started the Sapphire Rapids (SPR) server chipset effort for coreboot. Companies needed coreboot on a modern server chipset; the SPR effort showed a way to get it. The final piece was the structuring of a multi-party NDA to allow joint collaboration.

In this talk, I'll discuss how a project designed for minimized UEFI platforms has now come to include coreboot, and what may come in the future, as more companies join in multi-party NDA efforts on even newer chipsets.

This talk will give an update of the current state of u-BMC and showcase its capabilities. The new project layout will be explained, how it came to be and what the road-map for the future is. In addition a few shortcomings of rivaling BMC stacks are shown and how u-BMC intends to overcome these. Emphasis will be put on the fact that this is still a greenfield solution that does not (yet) cater to industry standards like redfish or swordfish.

coreboot has to be lightning-fast, and developers are contributing a lot of their time to achieve lower and lower execution times. Without proper tools, however, it is hard to find some bottlenecks and improve inefficient code.

In coreboot there is a timestamps system, which allows one to mark the start and end of a particular period, store time points (in CBMEM), and analyze them later on. It is a useful, yet inefficient approach, as it requires manual placement in the code. There is a place for code profilers - powerful tools helping with such tasks, without requiring much manual work from developers.

Commonly available code profiling tools - like gprof - are not suitable for the coreboot environment, that may not provide resources like timers/interrupts required for sampling. There is another way to measure execution time - here the code instrumentation comes to the rescue. It provides a mechanism for injecting entry and exit handlers for functions, which can be coded to store exact times. With this in place, we can analyze samples stored in CBMEM in many ways - for example, by creating flame chart visualizations.

This talk will focus on the design and implementation proposals of a coreboot code profiler capable of running on a real device, as well as on proof-of-concept implementation with an exemplary output of such a tool. We will also go through the technical details and issues which arose during development with a presentation of solutions to these problems.

One of the core firmware responsibilities is preparation of a hardware description used by the OS for power management and devices configuration. Vast majority of mainboards running coreboot use ACPI tables as a format for conveying this information.

While there are examples of tables compiled during a coreboot build phase from ASL (ACPI Source Language), most of them, including System Service Descriptor Tables (SSDT), are generated at runtime in a form of AML (ACPI Machine Language) by acpigen library. Defining a configuration for drivers - which create entries in SSDT - is one of the most important and time-consuming parts of a bring-up process for any new board.

Currently, the developers need to perform a long-lasting and complicated process, in order to verify what is the outcome of changes introduced in the SSDT generation path. It includes booting the platform till the OS is up and running, which is often not possible due to… improper ACPI description - typical vicious circle. There is a need to make developers' lives easier and shorten the development cycle.

Application running on the build machine, which is able to emulate acpigen behavior and generate output AML files, may greatly help with mitigating the issues described above. Once the result is (almost immediately) disassembled into ASL, it gives a developer a chance to catch all issues early.

This talk will cover a deep dive into the SSDT generation process in coreboot. Furthermore, a proof-of-concept implementation of host-side SSDT generator will be presented, with focus on issues already solved and ones yet to be closed. Moreover, limitations of this solution, as well as possible future benefits including verification of ACPI tables correctness by CI system will be discussed.

The industry-standard way of creating firmware support for a new SoC is to start with a copy of the code from the previous SoC generation and then make the changes needed to work for the new SoC generation. While this has some advantages, it might also result in code being copied over that might no longer be applicable to the new SoC.
When developing the coreboot support for the Cezanne APUs, we took another approach that was suggested by a member of the coreboot community and built the new SoC firmware support in coreboot starting with an empty directory and added the needed functionality in small pieces. In this talk, I will present our experience with this approach, the advantages and disadvantages it has, what we learned from doing this, and in which cases this new approach might be the preferred one.

Thanks to Google Chromebooks, open-source firmware support in coreboot for
mobile devices is very well established. It allowed the successful enabling of
modern laptops for a variety of devices. A good example is an arsenal of Clevo
boards ported and used by many vendors and OEMs like Novacustom, TUXEDO,
System76. However, the desktop/workstation segment has been very much
neglected, leaving no other choice but to go with a few years old boards like
Coffee Lake Supermicro servers or Kaby Lake ASUS desktop. But the situation
dramatically changed when MSI PRO Z690-A DDR4 WIFI Alder Lake S board has been
ported to coreboot.

The presentation will explain the challenges met during the development of
Alder Lake S silicon and board support. It will also reveal certain
misconfigurations in coreboot and Intel FSP bugs found. The presenters will
also disclose future plans for firmware development. The project is a
game-changer for the gaming/performance hardware enthusiasts, given how much
interest it generated, which should benefit the coreboot project.

How do you know that your signing key is not being used for malicious purposes?
For example, a compromised key can be used to distribute firmware that contains
malware or to forge TPM quotes. The short answer is that it is difficult to
detect this type of compromise. Unless your key-usage is transparent enough,
you have no consize view of the signatures that an end-user may encounter.

Meet Sigsum, a free and open source software project that brings transparency to
signed checksums. The goal is to detect every signature that an end-user
accepts as valid. This goal is achieved using a minimal transparency log
design that can be used as a building block to secure the supply chain and more.
For security, we rely on standard cryptographic assumptions and an attacker that
cannot control more than m-of-n independent parties. Throughout the talk you
will learn more about Sigsum's approach towards transparency logs.

During the boot of a PC, it is now common to have each stage store measurements of the next one into a TPM, in order to keep a tamper-proof log of the boot chain. Those measurements are then leveraged to seal secrets, eg. a disk encryption key, or to report the state of the device to a remote server in cryptographically secure way, using a procedure known as remote attestation.

Remote attestation has slowly gained traction over the last few years, most notably among cloud providers such as Azure, to guard access to online resources. It is also a key element in validating dynamic root-of-trust measurements (DRTM), which reduce the trusted computing base compared to traditional UEFI-based boot chains, but require a trusted third-party to validate the final state of the system. Unfortunately, little progress has been made recently to enable individual users without access to server resources to reap the benefits of remote attestation. This is particularly frustrating considering that almost everybody carries a small trusted server with them all the time: smartphones.

Building upon an idea by Matthew Garrett[^1], we introduce Ultrablue (User-friendly Lightweight TPM Remote Attestation over Bluetooth), a solution to securely inspect and validate a TPM event log from a phone. Ultrablue consists of a command-line attester, running on a computer, and an Android graphical application, running on a trusted phone, communicating over encrypted Bluetooth low-energy (BLE). Pairing the phone and computer is made easier and more secure through the use of a QR Code. After a trust-on-first-use provisioning phase to enroll the computer on the phone, the phone can check that the boot chain has not been compromised in later boots. Sample scripts and a self-contained virtual machine are also provided as a reference of how to integrate Ultrablue in the boot process to guard disk encryption by a secret delivered by the phone.

Future work includes improving the user interface to inspect and validate unexpected event logs, adding support for more versatile verification policies, and integrating Ultrablue into existing hardened systems such as Safeboot (safeboot.net).

The Ultrablue project has been developped at ANSSI (ssi.gouv.fr) by Loïc Falkau--Buckwell, under the supervision of Nicolas Bouchinet and Gabriel Kerneis.

[^1]: Linux Conference Australia, 2020. https://www.youtube.com/watch?v=FobfM9S9xSI

LinuxBoot uses kexec to transition to next kernel. Kexec is the lifeline of LinuxBoot. There are two kexec sys calls today. LinuxBoot currently uses kexec file load API, which simply takes file descriptors to kernel, initrd and a cmdline string, and kernel does the heavy lift of processing and transition into next kernel. That has been working great. But as LinuxBoot expands adoptions, there is an increasing number of new requirements that file load kexec can’t help (at least, without pervasive kernel patches). For example, when booting AArch64, user may want to edit the device tree for booting next kernel.

This talk discuss the ongoing kexec workstream under LinuxBoot, such as the support recently added for classic kexec load into LinuxBoot for x86_64 (https://github.com/u-root/u-root/pull/2317), and AArch64 (https://github.com/u-root/u-root/pull/2437) , and behind-the-scene considerations and simplications.

Currently coreboot limits update of many boot parameters such as FSP UPD, firmware configuration, devicetree settings etc. This limits developers/advanced users to change settings on the fly and requires recompilation of code which might not be everyone's forte. Last year we presented a talk on mitigating the FSP UPD setting issue using Micropython as a payload.Initially Micropython was enabled on coreboot using libpayload using QEMU platform and later extended for x86 platform to do initial proof-of-concept.

This lightning talk presents the demonstration of the earlier proposed design as well as improvements over the proposed design to make it architecture agnostic and more secure by aligning coreboot's existing infrastructure of security (vboot).

This holistic approach of updating configuration without recompilation of the image will allow coreboot to reach a wider audience and mitigate single most complaints from most of the OEM/ODMs who might want to change many configurations on the fly.

The two prominent x86 firmware solutions, EDK2 & coreboot have divergent designs on how information is passed between programs. The coreboot project uses coreboot/LinuxBios (the structure dates for early 2000) tables to inform the payload. EDK2 generally uses HOBs to pass information between modules. Both have their limitations: e.g. coreboot tables need to be 4 byte aligned which makes decoding on 64bit systems problematic. HOBs tend to be versioned, which makes agreeing on the struct format a hurdle and have a 64K size limitation. In 2007 Linux introduced the flattened devicetree (FDT), to do exactly that: inform the OS about the hardware. It is a very good match for the payload handoff that we want to achieve in both EDK2 and coreboot. FDT is an industry standard that is very widely deployed on all sorts of hardware and software projects, with easy to use code. Due to the widespread use of FDT and existing implementations in both EDK2 and coreboot (and of course Linux) to support the format, it is expected to be a simple yet effective solution of doing a payload handoff. In line with that, CBOR, a newly emerged communication protocol is gaining momentum in deployments from firmware to OS level usages.
This document will discuss how to implement a handoff between coreboot and EDK2 using either CBOR or FDT as a handoff structure, and compare both implementations.

SBoM Annotations and Audits

When firmware is only available in binary form, i.e., the end user or corporate
entity has no access to its source code, quality and security assessment is
limited by legal constraints, and fixing bugs and flaws harder to achieve. While
possible escape hatches have been developed, such as replacing large parts of
the stock firmware with auditable environments like LinuxBoot, some uncertainty
still remains regarding drivers and other components that cannot be removed.
However, there are still options to help oneself where the OEM or other vendor
does not offer the flexibility or assurance one needs: We can build up a
knowledge database of drivers, offer guidance towards patching or replacing
them, and provide the tooling to automate the process. With Fiedka the firmware
editor, components can be annotated and those annotations
exported for reuse. In this short talk, we will evaluate the necessary workflows
and discuss user experience design considerations around the process.

An automated gateware detection mechanism was devised in an effort to build a software
system with the goal to improve performance and reduce software development time spent
on operating gateware pieces by reusing existing device drivers in the framework of the
chosen technology. This dissertation describes the design and implementation of a mechanism that automates gateware 1 device detection for reconfigurable hardware.
This dissertation first investigates the system design to see how each of the user specifications set for the KAT (Karoo Array Telescope) could be achieved in terms of design decisions, toolchain selection and software modifications.
The system implementation is then described and issues related to the process of integrating gateware, bootloader and kernel interfaces are discussed.

This year we pivoted the oreboot project, a downstream fork of coreboot
written entirely in Rust, to focus on RISC-V platforms, including the first
version of Beagle-V. We have focused our energies on platforms we can control from power-on reset, with no binary blobs.

Over the last year, the Allwinner D1 SoC, which offers a Linux-capable 64bit
XuanTie C906 RISC-V core and is found on many boards, has been fully ported,
including DRAM init. In addition, we picked up the work on the JH7100 SoC again
that was found on the BeagleV Starlight SBC, because it is also on the StarFive
VisionFive board, which has been provided to us by RISC-V International for the
developer support program.

In this talk, we present challenges we faced during
the development, including writing DRAM code from C code, not chipset documentation;
how we are taking advantage of the rapid growth of "bare metal" support in the Rust ecosystem and
how it has impacted our code, in ways large and small; and how the project is growing as new members
join.

Finally, we summarize the current status of the oreboot project.

Arthur will show you everything around coreboot's devicetree - This workshop is all about chips, busses, devices and trees!