Good morning!
Megan to strong-arm people into using their brains and provide the results.
As embedded systems become increasingly interconnected, the demand for robust platform security and integrity has surged. Trusted Platform Modules (TPM), currently in version 2.0, are becoming increasingly beneficial for enhancing security in embedded systems. TPMs provide hardware-backed mechanisms for critical functions such as random number generation, cryptographic key generation, key binding and data sealing.
This presentation will explore the capabilities of TPM 2.0, focusing practical use cases and the integration of TPM 2.0 within Yocto, including:
- Device identification
- Supporting secure boot mechanisms to establish a reliable chain of trust
- Encrypting user data without the need for user passwords
- Managing application credentials securely
This talk introduces an open-source hardware project focused on the design and integration of a TPM 2.0 add-on board for the Raspberry Pi 5. Built around the Infineon SLB 9672 chip, the board enables trusted computing by securely managing cryptographic keys and supporting features such as disk encryption, device authentication, digital signatures, measured boot and True Hardware Random Number Generator (TRNG),
The board has been designed as a compact two-layer printed circuit board (PCB) using the free and open-source software KiCad and connects via SPI to the Raspberry Pi’s 40-pin header. All hardware design files are published on GitHub under the permissive Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
Software integration is achieved through a custom Linux distribution built with the Yocto Project and OpenEmbedded, using the community-maintained meta-raspberrypi layer. TPM 2.0 support is provided via the tpm-slb9670.dtbo device tree overlay, which is included in the official Raspberry Pi Linux kernel and is compatible with the SLB 9672 due to its identical SPI interface. The board’s functionality has been verified using TPM2 tools, including self-tests and hardware random number generation.
The talk is appropriate for anyone interested in open source software and hardware development for Raspberry Pi.
With the CRA deadlines coming, it is important to ensure that you can comply with the Software Bill of Material (SBoM) requirements that it stipulates. Fortunately, Yocto has a robust and comprehensive SBoM integrated into it, which can aid in ensuring compliance. In this talk, Joshua will provide information and tips about how to configure your Yocto builds for CRA compliance and justification of compliance.
The Yocto Project offers flexibility and control — but in real-world products, that flexibility can quickly become complexity. In this session, Witekio shares practical lessons learned from dozens of commercial Yocto implementations across industries such as industrial control, home appliances, medical devices, and off-highway vehicles. We’ll discuss how product requirements shape Yocto choices, where common pitfalls arise, and how to structure Yocto projects for maintainability, security, and product longevity. Whether you’re starting your first Yocto-based product or scaling across multiple platforms, this session offers pragmatic guidance from real deployments.
meta-security is one of the main layers with security-related tooling in the Yocto Project. In June 2025, Scott and Marta became its new co-maintainers, and in this session they are going to share the current state of the layer, and the work currently in progress (mostly on bringing back CI and restoring the patch flow). They will then share their ideas on the next steps, and will ask the community for their feedback.
Since the Linux kernel became a CVE Numbering Authority (CNA), the number of associated CVEs has increased. Security teams must address these CVEs to meet regulatory and customer requirements, increasing their workload unless automation is implemented. In this talk, we analyze the status of CVEs for each LTS kernel branch. Then, we demonstrate how leveraging CVE kernel metadata and recent SPDX generation enhancements within oe-core can reduce CVE false positives by 70% and provide detailed responses for all kernel-related CVEs. This process uses output from vex or the cve-check bbclass as input. Additionally, it enables more detailed per-binary information about the source code used to compile any package built with The Yocto Project.
The current way of generating initramfs images involves creating a separate image recipe and building that, in theory, can have nothing in common with the main rootfs. That makes it virtually impossible to recreate it on-target when doing package based updates.
Software‑supply‑chain attacks increasingly exploit the dependency graphs hidden inside container base images. General‑purpose binary distributions can drag in hundreds of packages, making it difficult to generate accurate SBOMs and keep up with CVE patching. In this session you will learn how to use the Yocto Project to build lean, auditable container base images and matching package repositories that can serve as drop‑in replacements inside existing Docker or Podman build pipelines.
This session presents a modular test bench architecture we implemented internally to validate our embedded Linux developments. It focuses on testing Linux distributions on different hardware platforms, automatically within a CI/CD infrastructure, to ensure robustness across software and hardware integration.
Somewhat generic solution (proof of concept) for an OEM's customer to flash their products in their premises
Challenge your OE/Yocto/Bitbake knowledge and the rest of the crowd who thinks it knows better than you do. The winner will have the commit of her/his choice accepted by Richard Purdie ;-)