1.15 osfc-2026 2026-09-15 2026-09-17 3 00:05 https://talks.osfc.io https://talks.osfc.io/media/osfc-2026/img/logo_IoewCRK.webp Europe/Berlin Main Room // Grote Zaal Keynote 2026-09-15T09:00:00+02:00 09:00 00:20 Welcome Keynote - Open-Source Firmware Foundation (OSFF) by PHILIPP DEPPENWIESE and WERNER ZEH osfc-2026-106491-welcome-keynote-open-source-firmware-foundation-osff en false OSFC 2026 - Photo Philipp Deppenwiese OSFC 2026 - Photo Werner Zeh https://talks.osfc.io/osfc-2026/talk/WC9LHF/ https://talks.osfc.io/osfc-2026/talk/WC9LHF/feedback/ Main Room // Grote Zaal Keynote 2026-09-15T09:20:00+02:00 09:20 00:20 Welcome Keynote - 9elements by Christian Walter osfc-2026-106493-welcome-keynote-9elements en false OSFC 2026 - Photo Christian Walter https://talks.osfc.io/osfc-2026/talk/WG7EJ9/ https://talks.osfc.io/osfc-2026/talk/WG7EJ9/feedback/ Main Room // Grote Zaal Talk 2026-09-15T09:45:00+02:00 09:45 00:30 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. osfc-2026-101749-open-firmware-beyond-the-hyperscalers-outcomes-from-the-premday-user-group Erwan Velu en false OSFC 2026 - Photo Erwan Velu https://talks.osfc.io/osfc-2026/talk/T3CSGU/ https://talks.osfc.io/osfc-2026/talk/T3CSGU/feedback/ Main Room // Grote Zaal Talk 2026-09-15T10:30:00+02:00 10:30 00:30 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 osfc-2026-102523-memory-mapped-fpga-peripherals-on-zephyr-fmc-and-qspi-approaches Sahaj Sarup en false Demo FMC SRAM BUS Demo QSPI PSRAM OSFC 2026 - Photo Sahaj Sarup Slides https://talks.osfc.io/osfc-2026/talk/9HUU8E/ https://talks.osfc.io/osfc-2026/talk/9HUU8E/feedback/ Main Room // Grote Zaal Talk 2026-09-15T11:30:00+02:00 11:30 00:30 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. osfc-2026-101738-setting-boundaries-securing-overlooked-op-tee-attack-vectors Marco Felsch en false OSFC 2026 - Photo Marco Felsch https://talks.osfc.io/osfc-2026/talk/GSLJUP/ https://talks.osfc.io/osfc-2026/talk/GSLJUP/feedback/ Main Room // Grote Zaal Talk 2026-09-15T12:15:00+02:00 12:15 00:30 This talk will go into detail how porting Tamago to the AST2700 went, what blockers came up and which milestones were reached along the way. This includes proper baremetal networking in Go and even implementing a small filesystem to work on the storage you usually find on these type of chips. I will show a small DCSCM board running the code in a short demo and some initial comparisons with other BMC stacks like OpenBMC and even Hubris or WalaBMC. osfc-2026-98960-running-baremetal-go-in-the-ast2700-for-simpler-server-management Marvin Drees en false OSFC 2026 - Photo Marvin Drees https://talks.osfc.io/osfc-2026/talk/UYLY99/ https://talks.osfc.io/osfc-2026/talk/UYLY99/feedback/ Main Room // Grote Zaal Talk 2026-09-15T14:00:00+02:00 14:00 00:30 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. osfc-2026-102512-the-switch-has-no-cpu-running-an-entire-fabric-switch-on-its-bmc Sam Cook en false Slides OSFC 2026 - Photo Sam Cook https://talks.osfc.io/osfc-2026/talk/RHDDHV/ https://talks.osfc.io/osfc-2026/talk/RHDDHV/feedback/ Main Room // Grote Zaal Talk 2026-09-15T14:45:00+02:00 14:45 00:30 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. osfc-2026-102256-a-whole-new-world-running-a-pba-on-bare-metal-uefi-with-tamago Christian WalterChristian Grönke en false Repository (github.com) Slides (pdf) OSFC 2026 - Photo Christian Grönke OSFC 2026 - Photo Christian Walter https://talks.osfc.io/osfc-2026/talk/KQ8LNV/ https://talks.osfc.io/osfc-2026/talk/KQ8LNV/feedback/ Main Room // Grote Zaal Talk 2026-09-15T15:30:00+02:00 15:30 00:30 Nearly 17 years ago, barebox forked from Das U-Boot with a simple question: Why can't bootloader developers have nice things? "Nice" meant feeling like the Linux kernel and that included portability and being free of per-board assembly. The catch: the kernel is nice because the bootloader does the unpleasant work of turning a reset vector into a place where portable code may run. Undeterred, barebox's very earliest code was written in C anyway, fueled by a heavy dose of GNU extensions, macro magic, linker-script choreography, and, in hindsight, behavior neither the C standard nor GCC ever promised. GCC was charitable — until its optimizer wasn't. This talk narrates how barebox came to confront its past: sometimes by writing better C, sometimes by admitting C wasn't the right language (ARMv8 MMU disablement: please don't). Some cleverness has Linux ancestry; much was grown locally. Topics span build time (hundreds of per-board entry points sharing common relocatable objects), early init (C relocation code that fixes up its own relocations live), and runtime challenges (legitimate uses for accessing page zero; pointer-dereference woes across caches, MMIO, and hardware virtualization) and nifty features (green threads; pressing KASAN into tracking DMA-buffer ownership). You'll leave entertained (or slightly unnerved?), but with a feel for which problems belong in C and where we've exorcised nasal demons firsthand. osfc-2026-101723-barebox-and-the-last-nasal-demon-riders Ahmad Fatoum en false Slides OSFC 2026 - Photo Ahmad Fatoum https://talks.osfc.io/osfc-2026/talk/AAGWG7/ https://talks.osfc.io/osfc-2026/talk/AAGWG7/feedback/ Main Room // Grote Zaal Talk 2026-09-15T16:35:00+02:00 16:35 00:30 At hyperscale, detecting a firmware compromise is a solved problem; recovering from it is not. While Static Root-of-Trust Measurement (SRTM) provides reliable platform measurement, responding to a Secure Boot compliance breach typically results in a dead node awaiting manual intervention. Standard OS-level tools are blocked by System Management Mode, SMM, runtime locks, and proprietary out-of-band BMC APIs are too fragmented across heterogeneous fleets to provide a unified, automated recovery pipeline. We introduce a self-healing firmware state machine designed to bridge the gap between attestation and active remediation without distributing a powerful, portable signed key-clearing payload across the fleet. By delivering a custom EFI application via iPXE during the Boot Device Selection (BDS) phase, infrastructure control planes can evaluate a node's hardware compliance strictly in-band. Upon detecting unauthorized state drift, the application stages a vendor-agnostic, BDS-staged UEFI variable, `StageOptimzedDefaults`. This architecture circumvents runtime firmware constraints without violating the platform's security boundary. Together with our OEM hardware partners, we are currently adapting this mechanism, and are bringing this approach to OSFC for feedback. osfc-2026-101626-automated-bare-metal-remediation-closing-the-zero-trust-loop-with-staged-firmware-sanitization Giovanni Zantedeschi en This talk introduces a self-healing firmware state machine that bridges attestation and active-remediation, without shipping a powerful, portable, signed key-clearing payload across the fleet. false OSFC 2026 - Photo Giovanni Zantedeschi https://talks.osfc.io/osfc-2026/talk/LE99ND/ https://talks.osfc.io/osfc-2026/talk/LE99ND/feedback/ Main Room // Grote Zaal Talk 2026-09-15T17:20:00+02:00 17:20 00:30 With the rapid development of AI, its applications in the embedded software field are increasingly widespread. However, debugging OpenBMC in production environments remains notoriously difficult. Runtime logs are overwhelmingly long, making routine inspections highly time-consuming, and traditional troubleshooting relies heavily on manual analysis to reconstruct causal relationships. Even with current Agentic assistance, AI tools typically rely on superficial text-matching or vector embeddings to retrieve context. Because these methods lack deep semantic understanding of the codebase, directly feeding raw logs to AI agents rapidly exhausts context windows and produces factually incorrect diagnoses. This talk introduces a non-intrusive, zero-hallucination Agentic AI debugging workflow for OpenBMC. Instead of guessing logic, the Agent extracts deterministic ground truth from compiled artifacts. By leveraging binary analysis tools to pre-analyze symbol-rich binaries, we extract accurate call chains and static log strings. When a crash occurs, the Agent automatically captures runtime logs, reverse-matches isolated log lines to their precise source context, and traverses accurate call graphs to reconstruct the execution flow. By feeding the LLM this highly condensed, deterministic evidence chain rather than massive log dumps and raw source files, the Agent focuses solely on logical deduction. This approach requires zero modifications to the OpenBMC build process, ensures non-intrusiveness, significantly reduces token consumption, and enables end-to-end automated, highly accurate root cause analysis (RCA). osfc-2026-96642-agentic-ai-software-debugging-in-openbmc-extracting-ground-truth-from-binaries-to-eliminate-hallucinations Jia, Chunhui en false OSFC 2026 - Photo - Chunhui Jia https://talks.osfc.io/osfc-2026/talk/BVGH3B/ https://talks.osfc.io/osfc-2026/talk/BVGH3B/feedback/ Main Room // Grote Zaal Talk 2026-09-16T09:10:00+02:00 09:10 00:30 This talk introduces sp-test, a stand-alone harness for testing service-processor and root-of-trust firmware, and follows a single test from a developer's bench to hardware-based CI. A live demo runs on an off-the-shelf ST Nucleo board. osfc-2026-101698-fear-of-flashing-building-confidence-in-firmware-through-automated-testing Ben Stoltz en The release-note caution "Do not update if your system is working" may be less common than it was a decade ago, but the implied risk has not gone away. Easier recovery keeps a failed update from bricking the device, but it still wastes the customer's time and turns the next install from a button press into a risk to schedule. So customers learn to avoid installing, while developers learn to avoid change, all from fear of flashing. At Oxide, the Service Processor and Root of Trust run our Hubris-based firmware in place of a typical BMC or EC, on our servers, power shelf controllers, and network switches. There is no call-home; customers update when they choose, and once a rack ships, whether we can reach it is up to them. We require confidence before release, and hope to earn customer trust afterwards. Improving our testing regime is one way to strengthen both. sp-test is a new harness for direct hardware testing. It uses tools developers know, can emulate parts of the control plane, and lets a test declare what it needs so it runs where it applies and skips without failure when it doesn't. Tests once described only in PR comments can now be checked in and reused. Tests can run unchanged from a developer's bench to hardware-based CI, so someone with no board of their own can get results from scarce, shared hardware. The hardest tests to run are often the ones most worth sharing: the update path exercised as it is in production, code that runs only when something has gone wrong, and fault insertion tests. Telemetry, task dumps, and logs make test results actionable for someone who was not there when it failed. This pattern is not specific to Hubris or to Oxide; any team could build the same kind of testing. A live demo on an off-the-shelf ST Nucleo board makes it concrete. false OSFC 26 - Fear of Flashing - Ben Stoltz OSFC 26 - Fear of Flashing - Ben Stoltz OSFC 2026 - Photo - Ben Stoltz https://talks.osfc.io/osfc-2026/talk/QY9E7T/ https://talks.osfc.io/osfc-2026/talk/QY9E7T/feedback/ Main Room // Grote Zaal Talk 2026-09-16T09:55:00+02:00 09:55 00:30 This talk will discuss our work in bringing Linux to a hardware platform we (lowRISC) are developing - CHERI [Mocha](https://github.com/lowRISC/mocha) - complete with drivers for our hardware devices. CHERI [Mocha](https://github.com/lowRISC/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](https://cosmic-project.lowrisc.org/) 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. osfc-2026-101746-bringing-up-linux-on-a-memory-safe-cheri-risc-v-system Alice Ziuziakowska en false Talk Slides OSFC 2026 - Photo - lice Ziuziakowska https://talks.osfc.io/osfc-2026/talk/ADBDGY/ https://talks.osfc.io/osfc-2026/talk/ADBDGY/feedback/ Main Room // Grote Zaal Talk 2026-09-16T11:00:00+02:00 11:00 00:30 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 osfc-2026-100597-trustzone-bring-up-on-qualcomm-qcm6490-open-firmware-from-el3-to-linux-el2-with-a-buildroot-developer-workflow Jorge Ramirez-Ortiz en The Qualcomm RB3 Gen2 (QCM6490/Kodiak) is a commercially available AArch64 development board with upstream Linux and U-Boot support. The official firmware environment is delivered through Qualcomm Linux and meta-qcom — a comprehensive but heavyweight Yocto-based BSP that is the right answer for production integration but a slow inner loop for firmware engineers iterating on TF-A, OP-TEE, or the boot chain. This talk describes the boot architecture of the QCM6490 platform while providing a Buildroot-based developer workflow — integrated into OP-TEE/build.git — as a fast alternative to meta-qcom for firmware engineers. A single make all builds the full stack from source. From that point, rebuilding any individual component in the bootloader stack or the kernel UKI — and regenerating and flashing the resulting image — becomes a lightweight operation, enabling fast iteration at any layer. The architecture is the main thread. Topics covered include: - Exception level layout - Boot chain: PBL → XBL → BL2 (TF-A, signed with Qualcomm Sectools in TEST mode) → FIP (OP-TEE + U-Boot) → Unified Kernel Image (UKI) containing kernel, DTB, initramfs, and cmdline as a single EFI binary. - OP-TEE integration - DSP remoteproc chain: sourcing ADSP/CDSP firmware and embedding the qcom_pas PAS Trusted Application as an OP-TEE early TA - Developer ergonomics vs. meta-qcom: a fetch-blobs target that pulls Qualcomm boot binaries from public Qualcomm and CodeLinaro repositories in minutes, replacing the need for a full Yocto build during development. **Demo** The talk closes with a live run of the OP-TEE **xtest** regression suite on the board, demonstrating the full Normal/Secure World path end to end. The talk is aimed at firmware engineers working on Qualcomm Arm platforms, and more broadly at anyone integrating OP-TEE with a vendor boot chain that diverges from the standard reference flow. false OSFC 2026 - Slides OSFC 2026 - Photo - Jorge Ramirez-Ortiz https://talks.osfc.io/osfc-2026/talk/JQNFL3/ https://talks.osfc.io/osfc-2026/talk/JQNFL3/feedback/ Main Room // Grote Zaal Talk 2026-09-16T11:45:00+02:00 11:45 00:30 A live demo on how to use GNU poke on peeking/poking binary data and  tips and tricks useful for designing/documenting/debugging using poke.  GNU poke is an interactive, extensible editor for binary data.  Not  limited to editing basic entities such as bits and bytes, it provides  a full-fledged procedural, interactive programming language designed  to describe data structures and to operate on them. osfc-2026-105961-introduction-to-gnu-poke Mohammad-Reza Nabipoor en false OSFC 2026 - Photo - Mohammad-Reza Nabipoor https://talks.osfc.io/osfc-2026/talk/DDQUBN/ https://talks.osfc.io/osfc-2026/talk/DDQUBN/feedback/ Main Room // Grote Zaal Talk 2026-09-16T13:30:00+02:00 13:30 00:30 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. osfc-2026-101595-beyond-efi-what-is-next-for-firmware-and-booting Simon Glass en false slides OSFC 2026 - Photo - Simon Glass https://talks.osfc.io/osfc-2026/talk/PCYGKN/ https://talks.osfc.io/osfc-2026/talk/PCYGKN/feedback/ Main Room // Grote Zaal Talk 2026-09-16T14:15:00+02:00 14:15 00:30 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. osfc-2026-101829-shipping-the-hypervisor-in-firmware-a-static-partitioning-payload-for-slim-bootloader Bejean Mosher en false OSFC 2026 - Slides OSFC 2026 - Photo - Bejean Mosher https://talks.osfc.io/osfc-2026/talk/Z7PTYB/ https://talks.osfc.io/osfc-2026/talk/Z7PTYB/feedback/ Main Room // Grote Zaal Talk 2026-09-16T15:20:00+02:00 15:20 00:30 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, 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. osfc-2026-101741-openbmc-at-cloud-scale-scaleway-s-journey-to-firmware-autonomy Elyes ZekriGauthier CARPENTIER en Beyond Scaleway’s own experience, we advocate for cross-industry collaboration and co-design, leveraging communities and events such as Premday to align operator requirements and accelerate shared solutions. We also believe that building in-house expertise around open firmware is becoming a strategic capability for infrastructure owners seeking greater control, flexibility, and innovation. false OSFC 2026 - Slides OSFC 2026 - Photo - Elyes Zekri OSFC 2026 - Photo - Gauthier CARPENTIER OSFC 2026 - Photo - Elyes Zekri & Gauthier CARPENTIER https://talks.osfc.io/osfc-2026/talk/XHMWY9/ https://talks.osfc.io/osfc-2026/talk/XHMWY9/feedback/ Main Room // Grote Zaal Talk 2026-09-16T16:05:00+02:00 16:05 00:30 It is clear that booting a system based on an application processor requires multiple binaries and possibly multiple hardware components - at the very least, one to initialize the DRAM and one to run in it. This implies that the various components of the chain, however many, need to be aware of the respective next and previous one somehow: Any component has to know the source, the protocol, and the destination for loading the next one, and the build system needs to create an overall image for the target platform, typically also requiring extra data structures that adhere to the mask ROM or other prior loader, possibly containing signatures or similar for a secure boot flow. With this presentation, we summarize the development of the oreboot and LinuxBoot build systems over time, what has been considered and attempted, and how things worked out, and compare with other firmware projects, such as U-Boot and coreboot. We explain why it is important to know and understand the full chain and its build process for both security and reliability, and finally provide a list of necessary features to be worked on for the future. osfc-2026-99146-boot-chains-and-build-systems Jiji Freya Daniel Maslowski en false slides (copy) slides Jiji Freya Daniel Maslowski - Photo https://talks.osfc.io/osfc-2026/talk/7788YB/ https://talks.osfc.io/osfc-2026/talk/7788YB/feedback/ Main Room // Grote Zaal Talk 2026-09-16T16:50:00+02:00 16:50 00:30 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. osfc-2026-101754-teaching-an-old-soc-new-tricks-native-raminit-for-bay-trail Mate Kukri en false Slides OSFC 2026 - Photo - Mate Kukri https://talks.osfc.io/osfc-2026/talk/PZQ8JW/ https://talks.osfc.io/osfc-2026/talk/PZQ8JW/feedback/ Main Room // Grote Zaal Event Info 2026-09-16T18:00:00+02:00 18:00 03:00 We're in Amsterdam!! A canal cruise was simply the obvious choice. Join us for an evening cruise through Amsterdam's historic waterways together with fellow OSFC attendees. Let's take in the full Amsterdam charm and continue the conversations in a slightly more scenic setting – with food & drinks on board 🍴🍻 **The plan:** - 6:00 PM – We head out from the venue together, easy 10-min walk to the dock, then hop on the boats - 6:30 PM – Boats set off for a 2-hour cruise through the canals - 8:30 PM – Back at the dock - 9:00 PM – Back at the venue **PLEASE REGISTER** or stop by the Help Desk to let us know if you want to join. See you on board :) osfc-2026-105958-social-event-canal-cruise Oscar en false https://talks.osfc.io/osfc-2026/talk/NMVXKZ/ https://talks.osfc.io/osfc-2026/talk/NMVXKZ/feedback/ Workspace // 2nd floor Workshop 2026-09-17T14:00:00+02:00 14:00 02:15 Building firmware that can boot an unmodified operating system across different Arm platforms requires more than implementing UEFI or ACPI. It also requires a practical understanding of open firmware standards, validation tools, and common integration issues. This workshop introduces the open-source Arm SystemReady Architecture Compliance Suite (ACS) from a firmware developer's perspective. Participants will learn how to prepare a platform, run compliance tests, interpret results from UEFI SCT, FWTS, and BSA/SBSA tests, and investigate common firmware issues that affect OS boot and interoperability. Beyond the testing flow, the session will provide an overview of the Arm SystemReady program, recent updates, and the open tools and reference platforms available to help developers build firmware that supports standard operating systems. The goal is to help firmware engineers adopt open standards earlier in development, reduce integration effort, and improve software portability across the Arm ecosystem. osfc-2026-103794-arm-systemready-workshop-open-platforms-and-firmware-development Ann ChengDong Wei en false https://talks.osfc.io/osfc-2026/talk/JBDWBK/ https://talks.osfc.io/osfc-2026/talk/JBDWBK/feedback/ Main Room // Grote Zaal Lightning Talk 2026-09-17T10:00:00+02:00 10:00 00:15 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. osfc-2026-102494-go-tcg-storage-state-of-the-project-and-the-future Christian Grönke en TCG Storage self-encrypting drives (SEDs) put full-disk encryption in the drive controller itself, exposed through the Trusted Computing Group's Security Subsystem Classes — Opal, Pyrite, Enterprise, and Ruby. In practice, managing them means wrestling with ComIDs, locking ranges, pre-boot authentication and shadow MBR, usually via legacy tooling like sedutil or vendor specific tools. go-tcg-storage takes a different path: a pure-Go, kernel-independent implementation of the TCG Storage stack, layered from a low-level drive interface (IF-SEND/IF-RECV over NVMe, SATA, and SAS) up through a core session library to a high-level locking API. This lightning talk covers three things: (1) a short primer on TCG Storage and why an open, library matters for firmware and boot security; (2) the current state of go-tcg-storage — what works, which drives and SSCs are covered, and where the rough edges are; and (3) the roadmap: broader SSC and transport coverage, PBA workflows, release and packaging, testing, and documentation. false Repository (github.com) Slides (pdf) OSFC 2026 - Photo - Christian Grönke https://talks.osfc.io/osfc-2026/talk/39MQKB/ https://talks.osfc.io/osfc-2026/talk/39MQKB/feedback/ Main Room // Grote Zaal Lightning Talk 2026-09-17T10:30:00+02:00 10:30 00:15 Secure-boot projects often end up with a zoo of nearly-identical bootloader images for development, factory, and field use with each variant adding more risk. In this lightning talk, I present barebox's Security Policy support, which facilitates adapting securely to each lifecycle stage and how the state transition can be controlled via eFuses, device-bound unlock tokens or hardware-rooted storage. osfc-2026-101729-runtime-access-control-in-the-bootloader Ahmad Fatoum en false Slides OSFC 2026 - Photo - Ahmad Fatoum https://talks.osfc.io/osfc-2026/talk/DERT3G/ https://talks.osfc.io/osfc-2026/talk/DERT3G/feedback/ Main Room // Grote Zaal Lightning Talk 2026-09-17T11:15:00+02:00 11:15 00:15 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 osfc-2026-96896-norbert-open-source-spi-flash-emulation Arthur Heymans en false OSFC 2026 - Photo - Arthur Heymans https://talks.osfc.io/osfc-2026/talk/FVUHU8/ https://talks.osfc.io/osfc-2026/talk/FVUHU8/feedback/ Main Room // Grote Zaal Lightning Talk 2026-09-17T11:30:00+02:00 11:30 00:15 "If you cannot use a CLI, you probably have no business in doing firmware." This used to be true. Firmware is a hard thing to get into. You need to get familiar with a lot of things before you can do something meaningful. At least part of this barrier is having to use a CLI. Rust has many advantages. When people advocate for rust it's usually about it being memory safe, rust having a good tooling like package managers and linters/formatters, a strong compiler telling exactly what you messed up, ... This is all very true and also applies when making CLI tools that relate to firmware development, but this talk wants to highlight another advantage of rust. Rust has a wasm target arch which makes it easy to support both a CLI as well as a web application in the same codebase. The advantage of a web application for beginners is substantial: no need to download and compile a tool, no need to copy a command of which you understand only half, just visit a website and be greeted with an intuitive UI. The goal of this talk is to showcase how making a webui alongside a CLI is possible and give some examples. Some examples https://rflasher.9elements.com https://rem100.9ements.com https://github.com/ArthurHeymans/NORbert/pull/9 (PR for web tool) osfc-2026-97648-rewriting-firmware-tools-in-rust-lowering-the-barrier-with-web-tools Arthur Heymans en false OSFC 2026 - Photo - Arthur Heymans https://talks.osfc.io/osfc-2026/talk/HMEUSQ/ https://talks.osfc.io/osfc-2026/talk/HMEUSQ/feedback/ Main Room // Grote Zaal Lightning Talk 2026-09-17T12:15:00+02:00 12:15 00:15 We all know the OVMF TianoCore2. The great virtual machine firmware framework used by VirtualBox and KVM (by default). It's a complete and beautiful reference implementation of the UEFI spec. But do we need the PEI phase? The SEC phase in a virtual machine? That we can directly start from a DXE (or PEI phase to setup DXE environment) that skips SEC phase and legacy burdens (via usage of VMCS/VMCB or corresponding control structure for firmware) directly. Hypervisor provides the ACPI tables and PCIe configuration space. So firmware is used more as a "get it done" layer to boot a modern OS than a full implementation. osfc-2026-95920-minimalist-uefi-implementation-for-virtual-machines Borhan Tuğsan Balcı en false Slide OSFC 2026 - Photo Borhan Tuğsan Balcı https://talks.osfc.io/osfc-2026/talk/C8URL3/ https://talks.osfc.io/osfc-2026/talk/C8URL3/feedback/ Main Room // Grote Zaal Lightning Talk 2026-09-17T12:30:00+02:00 12:30 00:15 The UEFI Forum is a global technology consortium that advances firmware innovation through industry collaboration while developing and maintaining the Unified Extensible Firmware Interface (UEFI), Platform Initialization (PI), and Advanced Configuration and Power Interface (ACPI) specifications. Together, these standards provide the foundation for platform initialization, firmware bootstrap, system configuration, power management, security, and operating system interoperability across modern computing platforms. A key strength of these specifications is their architecture-neutral design. Today, UEFI, PI, and ACPI are deployed across x86, Arm, RISC-V, and LoongArch systems, helping to enable a consistent software experience across an increasingly diverse hardware ecosystem. In this State of the UEFI session, UEFI Forum President Dong Wei will provide an overview of the UEFI Forum, recent developments in the UEFI, PI, and ACPI specifications, the Forum’s working group structure, Code First process. Attendees will learn how organizations and individuals can participate in future specification development and collaborate with the broader firmware community. The session will also highlight ongoing collaboration between the UEFI Forum and adjacent open-source communities, including the Open Compute Project (OCP) Open Platform Firmware (OPF) Project, where Dong serves as a Steering Committee representative. Attendees will learn about emerging opportunities for synergy between OCP initiatives such as OpenSFI and UPCI and the UEFI Forum’s standards efforts. Finally, attendees will receive updates on key industry topics including platform security, confidential computing, post-quantum cryptography, and other trends shaping the future of open firmware. osfc-2026-100966-state-of-the-uefi-open-firmware-standards-across-modern-computing-platforms Dong Wei en false OSFC 2026 - Slides OSFC 2026 - Photo - Dong Wei https://talks.osfc.io/osfc-2026/talk/EUBBBZ/ https://talks.osfc.io/osfc-2026/talk/EUBBBZ/feedback/ Main Room // Grote Zaal Open Mic 2026-09-17T14:00:00+02:00 14:00 00:20 Crabefi Is library to implement UEFI, that supports x86, aarch64 and riscv. One problem that kept biting it, was UEFI Set Virtual Address Mode. This runtime command allows the UEFI runtime to be called by the kernel in its preferred memory map. This does mean the runtime needs be able to relocate while running. No programming language has a proper solution for this. It's a huge footgun or in rust terminology, it's very unsafe. Crabefi works around this in a novel way. The runtime is a standalone binary that does not need to relocate pointers. Rust also avoids unsafe/undefined behavior with panic. Panic is basically a guaranteed footgun, as the kernel calls UEFI in ring 0. This talk will also explain how to avoid these panics in a provable way. osfc-2026-105984-open-mic-uefi-runtime-was-a-bad-idea-how-to-engineer-around-it-in-rust-in-a-novel-way Arthur Heymans en false https://talks.osfc.io/osfc-2026/talk/H8CK9F/ https://talks.osfc.io/osfc-2026/talk/H8CK9F/feedback/ Main Room // Grote Zaal Open Mic 2026-09-17T14:25:00+02:00 14:25 00:20 The Cyber Resilience Act (CRA) is EU product legislation that lists categories of important and critical products. Standards for these categories are being developed by ETSI and CEN-CENELEC. _Boot managers_ are one of them (Annex III, Class I): a manufacturer who applies the harmonised standard can self-assess conformity, otherwise a notified body has to be involved. Reporting obligations have applied since 11 September 2026 and the product standards are entering their final stage. As rapporteur of [ETSI EN 304 623](https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=74414), I give an overview of where things stand and which issues remain open, including what counts as a boot manager in this context in the first place. Firmware is often built from open-source components that were never placed on the market on their own. The talk closes with an idea for how device manufacturers and integrators can meet their due diligence obligation for such components ([CRA Art. 13(5)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng#art_13)). osfc-2026-105985-open-mic-open-source-firmware-and-the-cyber-resilience-act-cra fukami en false https://talks.osfc.io/osfc-2026/talk/VU7WBN/ https://talks.osfc.io/osfc-2026/talk/VU7WBN/feedback/ Main Room // Grote Zaal Open Mic 2026-09-17T14:50:00+02:00 14:50 00:20 “It passed on my laptop.” What can the next maintainer actually verify? WedgeBench is an open-source workflow that turns bounded malformed-input parser tests into reproducible, machine-checkable evidence. It combines a deterministic corpus, thin target adapters, structured artifacts, and validation. I’ll walk through the go-tcg-storage reference integration, deliberately alter a copy of the evidence, and show the validator rejecting the mismatch. We’ll examine what PASS establishes—and why it does not certify firmware safety, authenticate the author, or validate physical hardware. This complements fuzzing; it does not replace it. You’ll leave with a public workflow to try and a concrete pattern for maintainer handoffs. Bring your skepticism: challenge the assumptions, find a mutation the validator should reject but accepts, or nominate the next real target. Don’t trust the claim. Run the workflow. osfc-2026-105986-open-mic-don-t-trust-the-claim-reproducible-firmware-evidence-with-wedgebench Keith Gariepy en false https://talks.osfc.io/osfc-2026/talk/E8TZTM/ https://talks.osfc.io/osfc-2026/talk/E8TZTM/feedback/ Main Room // Grote Zaal Open Mic 2026-09-17T15:30:00+02:00 15:30 00:20 UEFI Secure Boot is an important feature that secures the root of trust. When configured correctly, it ensures that your kernel boots the way that *you* want, without malicious modifications. In coreboot, it's made possible by the SMMSTORE feature. But there's a problem: SMMSTORE was developed for basic functionality, not security. This talk is about the security vulnerability in the coreboot implementation of Secure Boot that's caused by decoupling implementation-level details, like verification, from performing the SPI write in coreboot, and how we fixed it by allowing part of UEFI into SMM to make this atomic again. osfc-2026-105987-open-mic-payload-mm-fixing-a-coreboot-secure-boot-vulnerability-with-a-new-smm-design Benjamin Doron en false https://talks.osfc.io/osfc-2026/talk/HHVLPX/ https://talks.osfc.io/osfc-2026/talk/HHVLPX/feedback/ Main Room // Grote Zaal Open Mic 2026-09-17T15:55:00+02:00 15:55 00:20 Arm server SoCs have grown immensely in complexity over the last decade. In this lightning talk we will recap the compute components that need firmware, which frameworks we typically use for them and how the whole stack works together. osfc-2026-105988-open-mic-typical-arm-soc-firmware-stack Tomas Pilar en false https://talks.osfc.io/osfc-2026/talk/L7WGR8/ https://talks.osfc.io/osfc-2026/talk/L7WGR8/feedback/ Studio // 5th floor Workshop 2026-09-17T10:00:00+02:00 10:00 02:15 This workshop introduces an early-stage web-based firmware analysis tool designed to make firmware security assessment more accessible to students, researchers, and security practitioners. Many organisations do not routinely include firmware analysis in their security workflows, even though firmware may contain insecure services, exposed credentials, weak configuration, unsafe permissions, or other security-relevant artefacts. The tool allows users to upload a firmware image and receive structured findings generated through automated static analysis, including extraction results, suspicious network indicators, authentication artefacts, permission issues, and transport security indicators. The workshop will demonstrate how low-level firmware evidence can be converted into clearer security findings, including severity information, contextual explanations, and NIST-aligned reporting to support governance and remediation discussions. Participants will be guided through example firmware analysis outputs and invited to critique the clarity, usefulness, and accuracy of the results. The session is intended to be practical and discussion-based, focusing on improving the tool’s usability, reporting structure, and relevance to real firmware security workflows. Feedback gathered during the workshop will inform the next stage of development and evaluation. osfc-2026-97102-automation-of-firmware-analysis-and-government-standard-reporting Paul Underhill en Attendees will see a live demonstration of the firmware analysis prototype, including security findings and severity ratings mapped to relevant NIST framework categories. The session will offer examples and discussions on the tool's usefulness, accuracy, and actionability. Participants do not need any prior knowledge of firmware reverse engineering, though a basic understanding of cybersecurity would aid in interpreting the tools' outputs. Feedback from both technical and non-technical attendees will inform future improvements to the prototype, including its interface, reporting structure, and relevance to practical firmware security workflows. false https://talks.osfc.io/osfc-2026/talk/BHNZZ9/ https://talks.osfc.io/osfc-2026/talk/BHNZZ9/feedback/ Studio // 5th floor Workshop 2026-09-17T14:00:00+02:00 14:00 02:15 A developer tooling pattern does double duty: everyday Hubris debugging tools `humility`, `faux-mgs`, and `faux-ipcc`, become the core for more formal tests anyone on the team can run. `sp-test` drives the tests, recording each run so tests and results can be shared, analyzed, and reproduced, on an emulator and on real hardware. osfc-2026-103798-hands-on-workshop-turning-manual-hubris-debugging-into-formal-shareable-tests Ben Stoltz en # Workshop preparation: Hands-on Hubris testing with `sp-test` > [!WARNING] > **Pre-release material, for education.** The workshop runs against > unreleased revisions of sp-test, sp-emu and Hubris, cut for a hands-on > session rather than published as a supported release. The interfaces the > exercises teach are still moving. Learn the shapes here, and check the tool > in front of you before you rely on a flag. What to do before the session, and the ways to take part. On the day we will make sure everyone has the workshop materials and hand out Nucleo boards. ## What `sp-test` does `sp-test` is a new tool to test Hubris. It: - drives the tools developers already use: the Hubris debugger `humility`, the Management Gateway Service tool `faux-mgs`, and others - flashes firmware by emulating the control plane's firmware-update flows, adding instrumentation and optional fault injection - uses a target's hardware and firmware properties to filter test suites, so tests that do not apply are skipped rather than failed - runs the same test against the `sp-emu` emulator and real service-processor hardware - records each run's environment and results so they can be shared and meaningfully compared - discovers and correlates SP and RoT debug probes, IPCC serial links, and Ethernet access ## Before the workshop - Pull the workshop container and run it once to confirm it starts: ```sh podman pull ghcr.io/oxidecomputer/sp-test-osfc26:osfc2026 mkdir -p ~/workshop-work podman run -d --name workshop \ -v ~/workshop-work:/work:Z \ ghcr.io/oxidecomputer/sp-test-osfc26:osfc2026 sleep infinity podman exec workshop bash -lc \ 'until faux-mgs -l warn --sp-sim-addr "[::1]:11111" state >/dev/null 2>&1; do sleep 5; done; echo ready' podman exec -it workshop bash -l ``` The container shares `~/workshop-work` at `/work`. Edit tests and exercises in your own editor and run them inside. Keep `:Z` on SELinux hosts (Fedora, RHEL and their derivatives) and drop it elsewhere. On macOS keep the directory under `/Users`. The podman VM shares that part of the filesystem and no other. Docker runs the image the same way. The link is confirmed by email before the conference. - Re-watch Matt Keeter's 2023 OSFC talk, "Unplugging the Debugger: Live and post-mortem debugging in a remote system" (https://talks.osfc.io/open-source-firmware-conference-2023/talk/9TTFZF/), on debugging a running Hubris system with `humility`. - For the design of Hubris itself, re-watch Cliff Biffle's 2021 OSFC talk, "On Hubris and Humility: developing an OS for robustness in Rust" (https://www.osfc.io/2021/talks/on-hubris-and-humility-developing-an-os-for-robustness-in-rust/). ## Ways to take part Pick the path that matches how far you want to go. You can start with the emulator and move up during the session. ### 1. Emulator only (quickest start) If you are happy running the full toolset against the emulated Hubris devices, the workshop container is all you need. One tag carries both architectures and podman takes the one your machine needs: about 268 MB down and 492 MB on disk for amd64, 266 MB and 508 MB for arm64. `sp-emu` can also run outside a container if you prefer. ### 2. Nucleo STM32H753ZI development board To test against a real Nucleo during the session, have ready: - an available Ethernet port on your laptop, configured for point-to-point IPv6 with the Nucleo (or an L2 switch with free ports) - an available USB port and a micro-B USB cable for the Nucleo's built-in ST-LINK debugger Configuring a laptop to talk to the board (IPv6, permissions, and other system administration) is well within an OSFC attendee's reach. Setup documentation helps; hands-on help for individual system issues during the session will be limited, since the container path avoids all of it. ### 3. Build from source (developer mode) To modify and build Hubris, `humility`, or the other tools, set up a full toolchain: - [install Rust](https://rustup.rs/). Hubris pins its own toolchain (`rust-toolchain.toml`); do not override it. - install `jq` and `unzip` from your package manager, and `toml2json` from crates.io: `cargo install toml2json`. - clone [Hubris](https://github.com/oxidecomputer/hubris) and build a Nucleo image that includes `control_plane_agent`. Master has it as of `46a7fb814`, so build from master: `cargo xtask dist app/demo-stm32h7-nucleo/app-h753.toml`. - Humility: fetch the prebuilt release binary if you can (recommended; building it from source interacts badly with the pinned toolchain). To build it anyway, clone [Humility](https://github.com/oxidecomputer/humility) and run `cargo install --path humility-bin --locked`. - build `faux-mgs`: clone [management-gateway-service](https://github.com/oxidecomputer/management-gateway-service) and run `cargo install --path faux-mgs --locked`. - `sp-test` has no public source yet. `oxidecomputer/sp-test` is an internal repository, and the snapshot cut for this workshop is not published either. Use the container, which carries the binary and the full source under `/opt/workshop/reference/sp-test`. To build from that copy: `cargo install --path sp-test --locked`. - if the Nucleo's built-in ST-LINK firmware is old, reflash it with [STSW-LINK007](https://www.st.com/en/development-tools/stsw-link007.html) (not available on illumos). ## Learning and experimenting progression Independent of which target you use, the progression from running some quick tests to the full Hubris developer experience varies by interest and experience. - **Stage 1, run and read**: run the example tests in the container and read their output. - **Stage 2, write and filter**: - write and modify tests and test suites - gate tests on capabilities, so a test skips where it does not apply - run test suites against different Hubris targets - **Stage 3, developer mode** (ambitious or take-home): modify and build Hubris, test the change with the developer tools, and write a test or fold it into a suite. ____ # Hands-on Hubris testing with `sp-test` OSFC 2026, Thursday 17 September, 14:30 to 16:30, Workspace // Workshop Room 2, Pakhuis de Zwijger. Two hours, classroom setup, 20 places. Schedule: https://talks.osfc.io/osfc-2026/schedule/ > [!WARNING] > **Pre-release material, for education.** The workshop runs against > unreleased revisions of sp-test, sp-emu and Hubris, cut for a hands-on > session rather than published as a supported release. The interfaces the > exercises teach are still moving. Learn the shapes here, and check the tool > in front of you before you rely on a flag. You explore the interfaces of Oxide's service processor, then write automated tests of it with `sp-test`, on an emulator and on real hardware. The session assumes no Rust or Hubris experience, and a short primer opens it. ## Before the workshop Three things, in the order of time needed to complete. Each has a section below. - **Download and run the container.** Everyone needs it. It holds the service processor emulation and the tools. - **Watch two earlier OSFC talks.** They cover the tools and the OS. - **Set your laptop up for the Nucleo**, only if you want to drive a board during the session. Bring a micro-USB cable, an Ethernet cable, and a free Ethernet port you can leave up without DHCP, for a point-to-point IPv6 link to the board. I bring some spare adapters and cables. ### Download the container The image is published on ghcr.io. The pull command goes out by email before the conference. Run it once at home, and again the day before the workshop to pick up any late change. One tag carries both architectures, so podman takes the one your machine needs and Apple Silicon runs the emulator natively. The pull moves about 268 MB and unpacks to about 492 MB, or 266 MB and 508 MB on arm64. `sp-emu` saturates one core, and anything that runs a container comfortably runs this. Podman and Docker both run the image, as does remote access to a machine that does. Pull it, then give it a directory of your own. The container shares that directory at `/work` and never owns it, so you edit tests and exercises in your own editor and run them inside. What you write there outlives the container: ```sh podman pull ghcr.io/oxidecomputer/sp-test-osfc26:osfc2026 mkdir -p ~/workshop-work podman run -d --name workshop \ -v ~/workshop-work:/work:Z \ ghcr.io/oxidecomputer/sp-test-osfc26:osfc2026 sleep infinity ``` Keep `:Z` on SELinux hosts (Fedora, RHEL and their derivatives). Drop it elsewhere. Starting the container boots an emulated gimlet-c: the SP, the RoT beside it, and bootleby. Expect tens of seconds. Wait for the SP rather than the shell prompt, then open as many shells as you like: ```sh podman exec workshop bash -lc \ 'until faux-mgs -l warn --sp-sim-addr "[::1]:11111" state >/dev/null 2>&1; do sleep 5; done; echo ready' podman exec -it workshop bash -l ``` Your shell lands with the exercises in `/work` and the environment already describing the running system, so `sp-test` needs no paths from you. Leaving the shell keeps the container running. `podman stop workshop` and `podman start workshop` resume the same emulator later; `podman rm -f workshop` throws the instance away and leaves `~/workshop-work` alone. On macOS the podman machine mounts `/Users`, so pick a directory under it. A home directory elsewhere, on an external volume say, cannot be shared into the container. The error names `statfs` rather than the mount: ``` Error: statfs /Volumes/.../workshop-work: no such file or directory ``` The emulated SP keeps its flash between runs, the way a board on a bench does. An image you flash in one session is still there in the next. `sp-emu-testbed.sh --reprovision` gets a clean one back. The image holds `sp-emu`, `sp-test`, `humility`, `faux-mgs`, some other support utilities, the exercises, and prebuilt Hubris archives. It is the tested path on every operating system. Once pulled, it needs no network. Download from a high bandwidth connection before the workshop if you can. Twenty people fetching a few hundred megabytes at once may not perform well on the day. There will be a server in the room handing out the image, and USB sticks as well, so arriving without it is recoverable. ### Watch two talks from earlier OSFCs Neither is required. Both leave the material fresh. - Matt Keeter, 2023, live and post-mortem debugging with `humility`: https://talks.osfc.io/open-source-firmware-conference-2023/talk/9TTFZF/ - Cliff Biffle, 2021, on the design of the Hubris OS: https://www.osfc.io/2021/talks/on-hubris-and-humility-developing-an-os-for-robustness-in-rust/ ### If you want to drive your own Nucleo, set your laptop up first The boards will be pre-flashed and ready to run. Build the tools natively: at least `humility` and `faux-mgs`. Prebuilt binaries are available, and you can compile your own. `attendee-prep.md` has the commands. Budget an evening, not ten minutes, and do it before you travel. ## What the session is Hubris is Oxide's Rust embedded operating system for service processors. `faux-mgs` and `faux-ipcc` exercise the same external APIs as our control plane. `humility` queries, debugs, and analyzes an SP or Root of Trust (RoT) on a board configured for development. `sp-test` drives tests portably, at a developer's bench or in hardware CI. Results land in a structured directory, ready to read, or for a CI run to post. `sp-test` matches every test against the target in front of it. A test lists what it needs as `required_capabilities` in its `test-info.toml`: strings like `sp:task:control_plane_agent`, `sp:task:net`, or `sp:socket:hiffy`. The target's capabilities are collected at run time from the Hubris archive, the running firmware, and the interfaces the testbed exposes. An unmet requirement skips the test rather than passing or failing it. One properly qualified test suite can therefore run against any testbed. Most of the two hour session is devoted to hands-on work. After a short review and demonstration that you can follow along with on your laptop, you explore the system, find something to break, and write a test that catches it. Most of what follows is open work time. Near the end, feedback, questions, and any demonstration you would like to give are welcome. One practical request: sit with someone if you can. There is one instructor for the room, so a neighbour is often the faster answer. Talking it through also helps you find a problem worth working on. ## Optional: your own board There are 20 STM32H753ZI Nucleo-144 boards to give away, handed out at the door. Start in the container and move to a board when you are ready. No exercise depends on having the physical board working. I also bring a small server with Nucleo boards attached that you can run tests against. Access to it will be resolved by the time of the workshop. Driving your own board needs two free ports: USB for the on-board ST-LINK, over a micro-USB cable, and Ethernet for a point-to-point IPv6 link to the board. If you have those and a spare micro-USB cable, bring them. Set the link up beforehand, so session time goes to the exercises rather than to network configuration. How you reach the board depends on your operating system, and this is the only place it matters. **Linux.** The container can connect to the Nucleo board. Pass the probe in and share the host network: ```sh podman run --rm --network=host \ --device /dev/bus/usb/001/006 \ --group-add keep-groups \ <image> bash ``` `--group-add keep-groups` carries your `plugdev` membership inside, so the probe opens without root. The device numbers come from `lsusb`, and they change when you replug the board. On Debian and derivatives, `apt install passt` first; rootless Podman needs it. **macOS.** Check that your home directory is somewhere the podman VM shares. A home on an external volume is not mounted by default, and `-v ~/workshop:/work` then fails with `statfs: no such file or directory`. `podman machine init -v <dir>:<dir>` fixes it. The container runs in a VM that doesn't allow raw USB access, so a physical board needs the tools built natively: `humility`, `faux-mgs`, `sp-test`, and `sp-emu`. Xcode command line tools and rustup are enough; no Homebrew packages are needed, and the probe opens without sudo. `attendee-prep.md` has the commands. Everything else works in the container, including the exercises that use a debug probe, because the emulator serves one over TCP. Note that the `st-util` method is not practical for our purposes. **Windows.** Same VM boundary. WSL2 with `usbipd` is the usual answer. People do build Hubris and `humility` natively on Windows. I have not, so I cannot help with it during the session. I am bringing roughly 10 sets of (USB cable, Ethernet cable, and USB Ethernet adapter). A set needs one USB-C or USB-A port for the adapter and a second port for the board. ## What you leave with - the tests you wrote, - sharable results that others can reproduce, - your own runtime environments to continue development and testing of Hubris And, I hope some new thoughts about testing embedded software. false https://talks.osfc.io/osfc-2026/talk/FK9WNA/ https://talks.osfc.io/osfc-2026/talk/FK9WNA/feedback/