Christian Walter, Christian Grönke; Talk
Pre-Boot Authentication (PBA) is a software that is used in the context of Self-Encrypting Drives (SEDs) - it unlocks the drive and makes it usable for the user.
TrustedPBA is a new PBA that is based on TamaGo and is executed as a EFI application. We wanted the simplicity of Golang combined with the benefits of the running the PBA in UEFI directly. TrustedPBA provides you with these benefits and is highly customizable:
- Different methods to unlock the drive - TPM PCR-based, TPM NVRAM-based, Password Input and many others
- Boot Policy Configuration
TrustedPBA enables the user to chainload every operating system which includes Windows which is a common limitation of 'classical' busybox PBAs.
Ritul Guru; Talk
In this talk, AMD will present its current open-source strategy for embedded platforms. Over the past few years, AMD has collaborated with 9elements and the broader open-source firmware community to enable multiple programs directly upstream. This session will provide an overview of the current status across these programs and highlight key milestones achieved. It will also offer a forward-looking perspective on the enablement of coreboot and openSIL, along with the primary focus areas for AMD and its partners.
Simon Glass; Talk
We have Tianocore for PCs and U-Boot for embedded systems. Both of these support EFI and can boot common Linux distros. So are we done now, with firmware and booting?
In fact we are just getting started on the road to genuinely open firmware and boot. EFI was designed in the 1990s for a closed-source environment. It has resulted in growing intermediation between firmware and the OS, with lots of code and complexity which is not really useful in an open source world. The good news is that we have a lot of the pieces in place to move to the next step.
This talk examines the process of assembling firmware and booting an OS, looking at how EFI handles these elements and the design decisions that led us here. It then proposes a set of incremental improvements leading towards a more open, straightforward and performant boot.
It ends with a demo contrasting the status quo with this new approach, including boot time, code size and security.
Alice Ziuziakowska; Talk
This talk will discuss our work in bringing Linux to a hardware platform we (lowRISC) are developing - CHERI Mocha - complete with drivers for our hardware devices.
CHERI Mocha is an open-source reference design for a secure enclave, which is a secure environment for running trusted code and security-sensitive applications that boots independently to the rest of the SoC it is co-located with. The modified CVA-6 core at the heart of the system implements CHERI RISC-V - an extension to the RISC-V ISA that extends ordinary registers into permission and bounds-checking capabilities that are checked in hardware, allowing for architectural memory safety guarantees.
In this talk, we will detail the work needed to bring this system - or any other RISC-V system - up from boot ROM to booting into CHERI Linux, explore interactions between hardware and various layers of software, and share the experiences of developing and debugging the hardware platform hand-in-hand with software efforts. We also discuss some of the differences required to support CHERI software/firmware during system bring-up, and where there was little difference over the standard Integer ISA. If you’re interested in novel computing architectures, learning the RISC-V boot stack, and aren’t afraid of debugging a new system with just an instruction trace and wave viewer, then this talk is for you.
CHERI Mocha is part of the COSMIC project, which is funded by DSIT and IUK (grant number 10168492). The hardware design including peripheral IP and software are all licensed under the permissive Apache 2.0 license.
Ben Stoltz; Talk
While the phrase "If your system is working, do not update it" may be waning, it still pops up in firmware release notes. It represents the risk of various failures: e.g. bricking through a misapplied or interrupted update, or by regressions in the new firmware.
Testing using the same initial hardware and software present on customer systems and in manufacturing is the surest way to improve confidence in update and recovery procedures as well as other expected behaviors. This talk describes how our developer-first tools, control plane emulations, and fault insertion are used to test our Service Processor and Root of Trust firmware prior to full-stack integration testing.
Sahaj Sarup; Talk
High-speed interfaces are rare on MCUs, and cost-effective FPGAs often come with limited LUTs, leaving developers caught between slow protocols like I2C/UART and the complexity of rolling a custom SPI protocol from scratch.
This talk explores a cleaner alternative: interfacing an FPGA as a memory-mapped device with an MCU running Zephyr, and extending that interface to expose gateware peripherals inside the FPGA. We'll cover two approaches, direct memory mapping over STM32's FMC bus, and a QSPI-based approach treating the FPGA as a SPI memory device, comparing their trade offs in speed, complexity, and flexibility.
Key takeaways:
1) Writing Devicetree for Memory mapped FPGAs using STM32’s FMC Bus.
2) Writing Devicetree for Memory Mapped FPGAs using Generic serialised SPI/QSPI interfaces.
3) Using the FPGA as MMU for external memory like HyperRAM.
4) Interfacing gateware peripherals in the FPGA from MCU running Zephyr
Arthur Heymans; Lightning Talk
SPI NOR flash is a very common IC used as a boot medium for both BMC and Host firwmare. Data can be read bytewise and pretty fast. Writes on the other hand are much slower. NORbert is an open source RTL project with open source tooling that emulates this kind of IC.
The content of the talk will be about why you'd want to emulate a SPI NOR flash and why you need to use an FPGA for this. I want to touch on what similar tools were previously available (dediprog EM100 & Trammel's spispy) and how NORbert improves upon them. IThe talk will showcase NORbert's functionality like logging and automated TOCTOU (time of check, time of use) vulnerability exploits. Lastly I will talk about the co-designed rust tooling which works also on the web.
Link to NORbert: https://github.com/ArthurHeymans/NORbert
Deepak Kodihalli; Lightning Talk
NVIDIA's upstream OpenBMC progress, challenges, and roadmap
Leon Gross; Talk
The firmware ecosystem is quite broad, ranging from linux-based systems such as OpenBMC, to RTOS-based or even kernel-less, bare-metal firmware stacks such as `caliptra-sw.
In this talk, I want to present to you the academic literature I encountered during my Master Thesis research and introduce you to the taxonomy and state-of-the-art methodologies to automatically analyze firmware blobs across domains. I want to motivate all of us to care more about the security of our firmware build artifacts and inspire you to adapt academic research to real life and find the nasty bugs leading to security vulnerabilities - "Gotta catch 'em all!"
Erwan Velu; Talk
In 2024, PremDay was introduced at OSFC as a new conference created by bare-metal infrastructure operators to share field experience with peers and hardware vendors. Two years later, the initiative has matured into a structured user group, and open firmware has moved from a discussion topic to a concrete workstream.
This talk proposes a synthesis of the open-firmware topics covered during the third edition of the PremDay conference and the actions that followed. It will summarize the main outcomes of the panel discussions, the growing call from infrastructure operators to adopt LVFS and fwupd for server firmware distribution, and the renewed interest in OpenBMC as a credible path away from opaque and closed-source management stacks. It will also present the creation of the SONiC portal, designed to gather technical knowledge, operational feedback, and a shared hardware compatibility list for the community.
The objective is not to present a single-vendor solution or a single company roadmap, but to show how a group of mid-scale infrastructure operators is converging on common expectations for firmware lifecycle, observability, transparency, and operational autonomy. These topics are now officially supported by the PremDay user group, giving them a broader base than an isolated company initiative.
For the OSFC audience, this is field feedback from operators who are not hyperscalers, but who still need firmware that is automatable, inspectable, supportable, and open enough to fit modern SRE practices.
Elyes Zekri, Gauthier CARPENTIER; Talk
This talk presents Scaleway’s journey in adopting OpenBMC at cloud-operator scale.
As a growing European cloud service provider operating more than 100,000 servers and thousands of GPUs, Scaleway is pursuing two strategic initiatives: adopting OCP Open Rack v3 (ORv3) to optimize rack-level power delivery, cooling, and modularity, and deploying OpenBMC as a unified firmware stack across server platforms to enable native Redfish support and greater firmware autonomy.
Bringing OpenBMC into production exposed several real-world challenges:
- Complexity of qualifying firmware on early hardware prototypes and pre-production platforms.
- Driving the organizational transformation required to integrate an entirely new firmware stack across multiple operational teams.
- Managing the coexistence of OpenBMC and legacy proprietary firmware within a heterogeneous infrastructure fleet.
To address these challenges, we established a close co-design relationship with hardware vendors through an iterative feedback loop and invested in developing in-house expertise. This approach enabled rapid internal adoption and progressively increased our autonomy over the firmware layer.
As we integrated OpenBMC into our infrastructure, we also explored how far we could go in developing our own firmware features to provide a consistent operational experience across OpenBMC-enabled platforms. During this talk, we will share practical examples related to hardware inventory management and monitoring, highlighting our efforts to harmonize firmware APIs across different server platforms.
Looking ahead, the focus will gradually shift from onboarding to long-term sustainment: keeping pace with evolving industry standards, maintaining firmware quality over time, and ensuring sustainable operational support.
Marco Felsch; Talk
Security requires isolation and for most ARM systems, this comes in the form of the ARM TrustZone, which divides the CPU into a secure and normal world. This allows the system to run a trusted exectuion environment (TEE) in the secure world and a rich execution environment (REE) in the normal world.
Of course, the TEE needs to be loaded from somewhere and be executed somewhere else. Doing this in a secure manner requires careful orchestration between multiple firmwares and failure to do so leads to serious vulnerabilities.
The talk starts off with a TEE setup that should sound familiar to many:
A prebootloader starts at the highest privilige level, does some DDR initialization and loads TF-A and OP-TEE as well as the final bootloader into memory. Then TF-A is invoked installing itself as secure monitor and OP-TEE as trusted OS before returning to the bootloader in a lower privilige level.
From there on, the CPU should fault trying to access secure memory, however hard the normal world tries. However, as Marco will show, there is no shortage on creative alternative ways to access memory and unfortunately, they are often overlooked leading to real world exploits.
This work culiminated into a number of patches across TF-A, OP-TEE and the barebox bootloader.
Guo Dong; Talk
This talk introduces HypervisorPayload — a Slim Bootloader payload that bundles and launches an open-source hypervisor (currently ACRN) as a single signed firmware artifact. Internally it has two parts: HvLoader, a small launcher that runs first, and the hypervisor binary it carries. The bootloader verifies HypervisorPayload once and forwards the platform VM configuration to it, eliminating the need for a separate hypervisor verification step.
At runtime, HvLoader retrieves the SBL VM configuration (CPU, memory, MMIO, IRQ, PCI passthrough) and passes it through to the hypervisor, loads guest kernels from boot media, builds a multiboot2 module table, and performs a one-shot register handoff to the hypervisor before leaving the control path. Statically pre-launched guests then boot natively on their dedicated vCPUs and passthrough devices — with no Service VM, no post-launched VMs, and no runtime control channel — allowing heterogeneous OS combinations (for example, Zephyr alongside Linux, Trusty alongside Android, or any mix of RTOS, general-purpose, and trusted guests) to run side by side on a single SoC with strong isolation and deterministic boot.
From the OS side, HypervisorPayload simply looks like the hypervisor that BIOS provides.
Mate Kukri; Talk
There has been a long-term urban legend around the difficulty of implementing native DRAM initialization in coreboot.
Firmware code running at this stage has no main memory available, and must grapple with a
small amount of CPU cache as data storage.
DRAM initialization entails retrieving memory chip characteristics for each channel, calculating common parameters, programming a large set of memory controller registers, and then DDR PHY registers.
Afterwards a set of SoC-specific and JEDEC-standard training algorithms must be performed to empirically derive a set of delays based on limited hardware-level signal feedback.
And all this has lived in proprietary "MRC" blobs with hardly any documentation for a long time,
deterring most coreboot developers from even attempting to produce open source code for this task.
This talk takes the 10+ year-old Intel Bay Trail platform, which has lived in coreboot ever since
Chromebooks were released with this SoC.
Instead of focusing on the low-level details of this specific platform, this talk will use it as a
case study for modern techniques for reverse engineering and then implementing open source code
for this DRAM initialization step.
It will showcase the use of SerialICE modernized with the Unicorn Engine to trace the operation of binary blobs, and how it can also be repurposed and combined with new harnesses to allow the rapid prototyping of the core algorithms. It will then show how careful, skeptical use of modern LLM-based tooling accelerated the conversion of this into a working, prototype-quality coreboot implementation capable of booting on multiple real boards.
Sam Cook; Talk
Almost everywhere OpenBMC runs, it is a server BMC stack, acting as sidecar to a much bigger host CPU, and it carries assumptions one can't see by reading the code. The only way to find assumptions buried that deep is to take the stack somewhere it was never meant to go, so we ran it on a high-radix fabric switch, then on a chassis of eighteen BMCs, and watched what broke. Our fabric switch has no separate control-plane processor, so the BMC is the switch's main processor.
Because there is no host CPU underneath, the BMC drives the fabric hardware itself. A daemon reads the switch ASIC's port counters directly, and through the module-management layer the BMC talks to every cable in the switch to read presence, temperature, identity, and more. All of that gets republished on D-Bus and projected into the DMTF Fabrics / Switches / Ports resource tree. We'll show where a standard built for servers bends to fit a fabric, and the one or two places where we decided an empty field was more honest than a server's answer.
We then put a switch into a chassis with multiple individually managed line cards, and that is where it gets interesting. Upstream bmcweb's Redfish aggregation is built for a single satellite and on our quest to aggregate multiple satellites, we discover how challenging lifting a seemingly simple assumption can be. We walk through each change as a concrete gap with a concrete fix, able to handle the single-server case the code was built for and our chassis paradigm.
Jorge Ramirez-Ortiz; Talk
A complete open-source TrustZone stack — TF-A at EL3, OP-TEE at Secure EL1, U-Boot and Linux at EL2 — built from source on the Qualcomm RB3 Gen2 (QCM6490/Kodiak).
This talk describes the boot architecture of the platform while walking through the constraints that make this SoC non-trivial to bring up: Sectools signing, running Linux at EL2 without Gunyah, QTEE vs OP-TEE device tree conflicts, and DSP remoteproc bring-up.
Qualcomm Linux ships official support via meta-qcom, but a multi-hour Yocto build is a poor inner loop for firmware developers; a Buildroot-based alternative — integrated into OP-TEE/build.git — enables fast iteration at any layer of the stack and live OP-TEE regression testing, which will be demonstrated.
Work will be upstreamed to OP-TEE/build.git
Christian Grönke; Lightning Talk
A quick tour of go-tcg-storage, the pure-Go library for driving TCG Storage self-encrypting drives. Where the project stands today, what might be next, and a perspective from someone stepping up to help maintain it.