OSS + ELC EU 2026

Modern Linux based distributed systems generally rely on bespoke "agent" services on each node for introspecting their state or issuing operations.

In this talk I'd like to explain systemd's vision of improving and cleaning up this logic, with the ultimate goal of avoiding any local agents but nonetheless making the system nicely introspectable and accessible, with modern technologies.

For this, we'll talk about the Varlink IPC system, and the numerous Varlink APIs systemd provides these days. We'll also cover the HTTP Varlink proxy, which opens up these APIs in a web-native way, with modern authorization mechanisms. We'll also discuss systemd's metrics collection/report generation subsystem, it's cryptographic properties and remote access to it.

In this talk I'd like to discuss the "systemd Credentials" concept, which was introduced back in systemd v250 and became a powerful mechanism for parameterizing Linux systems and services.

These credentials can be passed into systems and services, can be authenticated and encrypted by TPMs. They can be acquired from SMBIOS, via Cloud IMDS services, the UEFI System Partition, or local file systems and IPC. They have a well-defined life-cycle, and can be securely inherited down the process, container and VM hierarchy.

We'll compare them with other ways to parameterize systems and services, such as the kernel command line or environment blocks, and explain why systemd's credentials are often the much better approach.

While C is a spartan language by design and, as such, doesn't offer any automatic memory management, the linux kernel over the years has acquired several mechanisms that attempt to make it easier for developers to keep track of resources and control their lifetime.

These mechanisms use C compiler extensions for scope-based memory management, count object references, or rely on control flow provided by the lower-level subsystem code. They can also be an arbitrary mixture of multiple approaches.

As the C compiler by definition is unable to enforce ownership or reference counting and scope correctness, the users of these helpers must still leverage them correctly and respect the API contract.

The kernel has struggled with object lifetime issues for decades now and, while there are legitimate issues with the design of certain subsystems, some of these issues resulted from incorrect use of the kernel resource management APIs. A good example of this is scheduling devres actions for devices that will never be bound to drivers.

This talk will present different resource management mechanisms in the kernel along with examples of how to use them correctly and what mistakes to avoid.

Getting a driver into mainline Linux is a great step, but it is very different from downstream development. In downstream, the people writing the driver are often not the ones making the final product. Because of this, they have to implement 100% of the hardware features. But in the end, maybe only 60% of these features are actually used by product integrators. This creates dead code and increased driver complexity.

In this talk, I will show you the anatomy of a mainline Linux driver and guide you on how to write it for the upstream tree inclusion. We will see how to write generic code that is easy for the community to maintain in the long term. We will talk about using and extending existing kernel frameworks instead of making custom control paths or abusing current interfaces, which helps reduce ecosystem fragmentation. For embedded systems, we will also see how to make clean and extensible Device Tree bindings.

I will explain why we need to drop untestable downstream features to keep the code clean. Finally, we will look at how to format and check your patchset with tools like checkpatch, smatch, and new AI tools like Sashiko to ensure high kernel quality.

eBPF has become the backbone of modern Linux security tooling. Cilium, Tetragon, Falco, etc they all depend on eBPF's ability to hook kernel execution paths and enforce policy without a kernel patch or reboot. But there's a question the community has been slow to ask: who secures eBPF itself?
Working on bpfman, an eBPF program manager, exposed me to the trust assumptions baked into how programs get loaded, pinned, and granted kernel access. This talk covers what I found concrete attack surfaces that show up in real deployments, not theory.

We'll cover: the verifier's historical CVEs and what they reveal about its actual threat model, privilege escalation through CAP_BPF and unprivileged eBPF in distros that ship with it enabled, what program signing protects and what it quietly doesn't, and LSM hooks on BPF program loading that most teams aren't using yet.
The second half: BPF token scoping, how Ubuntu and Fedora are locking down the attack surface without breaking legitimate tooling,and a threat model checklist you can apply to your own eBPF deployment the same week.
If you're running eBPF-based security tooling in production, this is the talk I wished existed before I started.

When everything runs smoothly, memory usage is just another metric. But when out-of-memory situations strike, or you are tasked with cutting a workload's RAM in half, it suddenly becomes the most important metric in your system.

While Linux exposes dozens of memory-related counters, answering basic questions is notoriously difficult. Developers and system administrators often struggle to pinpoint exactly how much memory the system is actually using, what the true footprint of a single application is, and how much memory that application can safely consume before causing issues.

In this talk, Richard will demystify Linux memory metrics and break down how the OS organizes memory across kernel and userspace.

Attendees will learn how to accurately read and make sense of Linux memory counters, giving them a better understanding of how internal memory management actually works. The session will also cover practical techniques for debugging memory-related issues and OOM kills, leaving the audience with actionable ways to optimize their application memory footprints.