OSS + ELC EU 2026

The Linux kernel currently sees around 60 CVEs per week. With the EU Cyber Resilience Act (CRA) rapidly approaching this creates a serious challenge for anyone shipping commercial products based on it: a lot of additional vulnerability management and compliance work.

In this talk, we will introduce kernel-cve-triage, a tool developed under the umbrella of the Civil Infrastructure Platform (CIP). It addresses these compliance challenges with a unique approach, using the kernel’s Kconfig build configuration to determine which reported CVEs actually apply. With this method, we base our assessment only on the kernel source tree and its configuration and are build-system independent. This reduces false-positive CVEs by up to 95%, depending on the exact configuration and the set of vulnerabilities considered.

We will also cover the key differences compared to another major kernel CVE automation tool: the Yocto Project and its cve-check. Finally, we will give an outlook and suggestions on how to improve the current situation for the Linux kernel's users.

Managing vulnerabilities in the kernel has gotten more attention but also needs more effort due to the exploding number of CVEs. With the kernel now being a CNA since 2024, options have evolved, and most recently, since 596ad6c on openembedded-core/master, it has gotten "easy".

But this is not working for vendor kernels, as they lag mainline and a rebase is impractical, if not impossible, due to the vendor delta.
As vendor kernels are heavily used in the industry and a switch to linux-yocto is often not possible due to budget, timeline or vendor lock-in, a solution is needed.

I've built a solution that locates the fix for each detected CVE on the matching stable branch, emits a candidate backport patch, verifies it applies cleanly, checks (via koverage, at line granularity) whether the affected code is compiled, and classifies results into actionable buckets.
Output is a list of unaffected CVEs and a collection of patches for review. In my opinion, this is verified and evidence-backed patching rather than just a cherry-picked list.

I'd like to present a solution (layer) which includes this workflow and start a broader discussion about the issue with vendor kernels.

Flat Image Tree (FIT) is Das U-Boot’s preferred boot image format and underpins billions of embedded Linux boot flows, with adoption extending into other bootloaders such as barebox.

Its core idea of using the flattened device tree format for flexibility and code reuse, enabled widespread adoption, but also became a fertile source of subtle security flaws.

This talk traces FIT’s evolution from a pragmatic design choice to a widely trusted format, highlighting how its structure led to recurring weaknesses, culminating in CVE-2026-33243, a decade-old vulnerability whose exploitation bypassed verified boot for millions of devices.

Finally, Ahmad presents a proposal to improve FIT: a backwards-compatible scheme for whole-image signing that requires limited parsing, aiming to deliver stronger security guarantees without the format’s historical pitfalls.

Linux offers an impressive collection of security mechanisms, and recent years have added even more to the stack. Yet when reviewing embedded Linux products, I repeatedly run into a different problem: security features that are available, mature, and practical are simply not enabled.

Many embedded projects still start from vendor examples, reference BSPs, or existing products. As a result, design decisions made years ago often become the default for the next generation of devices. This talk focuses on a set of practical security mechanisms that embedded developers can deploy from the beginning of a project with relatively little effort.

Using examples from Yocto Project-based systems, we will examine features and tools such as:
- overlayfs with its advanced features
- filesystem permission hardening
- seccomp-based system call filtering
- fs-verity for file integrity protection
- fscrypt for protecting data belonging to different users and use cases.

We will discuss why they should be part of a base configuration and and show practical examples on how to do it.

Modern vehicles employ a highly integrated architecture with a relatively small number of powerful Electronic Control Units (ECUs). Many of these ECUs run Linux and present a sizable attack surface. To mitigate the resulting threats, SELinux offers an enhanced mechanism for enforcing the principle of least privilege.

Despite its strengths, SELinux remains complex and is not widely adopted. This talk offers a pragmatic introduction to SELinux, with concrete guidance you can apply to your embedded Linux project.

This session will cover basic permissions and type enforcement in SELinux, including which permissions are required for an application start-up. It will introduce the reference policy and guide you through writing a first “hello-world” policy. We will also discuss SELinux in the context of Yocto. Finally, we will conclude with lessons learned from our experience in large-scale projects.

OP-TEE is a widely adopted Trusted Execution Environment (TEE) commonly used on ARM-based SoCs. While it is highly portable and often features strong vendor support, achieving a functionally working setup is only half the battle. There are surprisingly many pitfalls where a developer can successfully integrate OP-TEE, only to introduce subtle security misconfigurations that silently undermine the entire system's threat model.

In this talk, Richard will outline the hidden security traps and integration challenges he has encountered over the past few years on custom hardware. Attendees will learn which footguns to watch out for, ultimately saving them the countless hours Richard spent debugging these exact issues.

Embedded Linux build systems such as The Yocto Project and Buildroot rely on reused build artifacts and external inputs, while these represent an improvement in build time for subsequent builds, also create opportunities for supply chain attacks that are difficult to detect.

This talk demonstrates practical attack vectors, showing how intermediate object files produced by make in Buildroot can be modified during the build to introduce malicious behavior without changing source code, and also demonstrate its possible to poison Yocto Project shared state (sstate) cache artifacts to propagate compromised binaries.
These attacks are validated end-to-end by executing poisoned binaries in the final Linux image under QEMU.

I will then present mitigation strategies, focusing on signing and verification of the sstate artifacts and improved control over build inputs. The discussion covers integration approaches and tradeoffs between security, performance, and developer workflows.

Attendees will gain practical insight into real-world risks when creating customized Linux distributions and concrete steps to improve their build system's security.

Modern embedded Linux devices must balance security, maintainability, and operational flexibility. While the Linux kernel provides powerful security primitives such as namespaces, cgroups, eBPF, and dm-verity, integrating them consistently across products remains a challenge.

This session explores how systemd has evolved beyond a traditional init system into a security and lifecycle management framework for embedded Linux platforms.

Using practical examples, we will examine how systemd Portable Services enable immutable application deployment, how dm-verity protects software integrity from storage to execution, how systemd leverages eBPF for kernel-enforced sandboxing and policy enforcement, and how cgroup-based resource management can contain both faults and attacks.

Attendees will learn how these mechanisms interact, how they can be integrated into Yocto-based systems, and how systemd can act as the orchestration layer between applications and modern Linux kernel security features.

Rather than presenting isolated hardening techniques, this session introduces a practical architecture for designing maintainable, resilient, and secure-by-default embedded Linux products.