Events in room UA2.114 (Baudoux)

Opening remarks and housekeeping.

Deutsche Bahn, with its 230,000 employees and hundreds of subsidiaries, is far from an average organization. Yet it faces the same challenges under the CRA as many others. In this session, we will show how we connected the concrete requirements of CRA compliance with our broader effort to bring transparency to our software supply chains. This forms the basis for security and license compliance processes, as well as for proactively shaping the ecosystems we depend on.

We will outline our strategy for addressing the expectations tied to the different roles we take on -- customer, manufacturer, and indirectly even steward -- from both organizational and technical angles. Given the diversity and scale of Deutsche Bahn, we rely on modular FOSS tools that offer the flexibility to adapt to varying stakeholder needs and evolving regulation. This flexibility is a core element of our approach. Join this session to learn how we align strategy and technology to make this work.

Note: This talk will be enriched by the session Deutsche Bahn's Approach to Large-Scale SBOM Collection and Use that puts an emphasis on the tooling aspects and the implementation in DevOps processes.

EV charging stations expose a uniquely difficult CRA landscape: A single physical device can be accessed through very different user paths: ISO 15118 (Plug&Charge), RFID cards, mobile apps, credit-card terminals, and OEM-backends. Between the end user and the actual product manufacturer sit multiple intermediaries (CSMS, OEM cloud, roaming hubs, payment processors), each with partial control over configuration, telemetry, and security posture. How to deliver all the CRA obligations across this complex eco system? At the same time a typical Charging Station Operator (CPO) has to manage over 300 different manufactures, models, firmware images and cyber security might differ from monitored private charging stations up to high-power public charging stations.

Rather on relying on "out-of-band" CRA management, a better approach might be to integrate all CRA cyber security obligations and especially the vulnerability management deeply into the commonly used management protocols like the Open Charge Point Protocol (OCPP). This removes the disconnect between CRA compliance work and operational reality.

Work in the Open Charge Alliance (notably the Cyber Security Task Group), CyberStand.eu’s CRA alignment efforts, and the newly NLnet NGI Zero Commons–funded EVQI project is already pushing concrete interfaces in this direction: Device-model variables for CRA readiness, structured vulnerability and lifecycle metadata, cross-vendor health monitoring, and standardized audit-trail exports suitable for CRA Article 10-15 reporting.

This session outlines how CRA obligations can be realized in a heterogeneous, multi-vendor charging ecosystem with an emphasis on operators managing 50000+ of devices. It shows which processes must be automated, which artefacts need to be transported over OCPP, and how deep protocol-level integration enables consistent, scalable CRA compliance across an extremely diverse EV-charging landscape.

Erlang/OTP is an open source programming language designed for the development of concurrent and distributed systems. Created 40 years ago and open sourced in 1998, Erlang is used by Ericsson, Cisco, WhatsApp, Discord, and Klarna for mission critical applications as well as loved by a broad community of open source developers. With the advent of the Cyber Resilience Act (CRA), the Erlang/OTP team, jointly with the Erlang Ecosystem Foundation (EEF), began to prepare the project to meet CRA requirements.   In this presentation, Kiko will describe and dive into the various supply chain best practices implemented by the Erlang/OTP project: the creation of Source Software Bill-of-Materials (Source SBOMs), automated vulnerability scanning of dependencies using OSV, creation of OpenVEX statements, vulnerability handling in collaboration with the EEF as CNA, and contributions to towards other open source projects [[1],[2],[3]] to improve the security posture of the ecosystem. Moreover, Kiko will provide an insight into the lessons learned from implementing these measures in an open source project.

Embedded products are at the core of the Cyber Resilience Act, yet they face unique compliance challenges. Hardware vendors ship heavily patched BSPs, software modules often diverge from upstream, and reliable identification of modified components is still far from solved. For teams building products on top of these layers, translating CRA requirements into daily engineering practice is not straightforward.

This talk provides a practical overview of where CRA compliance currently stands for embedded devices, using Yocto Project–based workflows as a representative example. We will explore what is already achievable today with existing tooling (SBOM generation, vulnerability scanning, provenance capture), and highlight the gaps that still require industry-wide definitions - from consistent software identification to handling vendor modifications and long-tail dependencies.

Participants will gain a grounded, realistic understanding of how CRA obligations map to actual embedded development, what can be implemented now, and where the ecosystem still needs collective work to reach a "working" state.

The Cyber Resilience Act (CRA) is reshaping expectations around open source software, introducing new requirements for security, traceability, and documentation. While maintainers are responsible for technical compliance, community managers play a critical but often overlooked role in helping projects adapt. This session is designed for community managers, project maintainers, stewards, and open source contributors interested in practical CRA readiness. The focus is on practical enablement by Community Managers, exploring how they can support compliance without assuming legal liability.

We’ll show how Community Managers can: - Communicate CRA-relevant processes to contributors, downstream adopters, and vendors - Structure documentation, governance pages, and onboarding materials for clarity and discoverability - Protect newcomers from unnecessary compliance burden, keeping contribution welcoming and accessible - Support maintainers, triaging non-technical questions, coordinating workflows, and preventing burnout Facilitate cross-project collaboration, shared tooling, and evidence collection practices - Manage vulnerability communication to maintain trust and transparency

The objective is for attendees to leave with practical strategies, templates, and examples that make CRA compliance manageable while keeping open source communities healthy and contributor-friendly. This session is ideal for community managers, project stewards, maintainers, and anyone interested in the human side of CRA readiness in FOSS projects. Attendees will leave with key takeaways: - Understand CRA’s indirect impact on community management and a checklist of how tos - Learn concrete ways to keep projects welcoming despite increased compliance expectations - Explore templates and workflow ideas that reduce friction for contributors and maintainers alike - See examples of cross-project coordination and documentation practices that support CRA readiness

This session emphasizes practical, community-driven solutions focusing on doing and not debating legal strategy making CRA compliance achievable and sustainable for FOSS communities.

This panel brings together experts to discuss the practical realities of implementing the CRA steward role, as defined by the regulation, and how organisations are approaching its execution. Panelists will explore how the concept of CRA stewards is being interpreted, what responsibilities are emerging in practice, and the challenges organisations face in preparing for this new function. They will also highlight which elements remain unclear, what support or guidance is still needed, and how future work at the level of EC and broader ecosystem can help refine and operationalise the steward role effectively. The panel aims to offer concrete insights for organisations navigating this evolving responsibility.

Security teams are currently drowning in vulnerability data, but the Vulnerability Exploitability eXchange (VEX) offers a solution by providing machine-readable clarity on which exploits actually matter. This technology is rapidly evolving from a "nice-to-have" efficiency tool into a critical compliance enabler for the EU Cyber Resilience Act (CRA), which mandates effective vulnerability handling for the European market.

In this session, Georg and Rao present the findings from the VEX Industry Collaboration Working Group, a group of industry leaders driving the development and application of VEX. The group identified a set of challenges and gaps hampering adoption, ranging from the different evolving technical directions in VEX formats to practical barriers such as discovery and distribution of VEX documents, immature tooling, and education. Rao and Georg will outline a shared path forward, advocating for the creation of a common distribution system, development of necessary tooling, and establishing a forum for collaboration between industry partners and open source projects to drive adoption and education.

The Cyber Resilience Act (CRA) requires a risk-based approach when developing and supporting products, even those that are only software. The most important part of this is the cybersecurity risk assessment. This document is the main thing that decides which essential cybersecurity requirements you must follow for your product and which ones you don't need to implement. If you don't have this cybersecurity risk assessment, your product will be seen as not compliant in the EU market, no matter how good it is overall. You are in charge of creating this risk assessment.

In this session, we will learn the steps of this formal and documented process to set up a compliant and reliable way to manage cybersecurity risks for your products with digital elements.

We will draw inspiration from standard industry practices for information security risk management and the recently released EN 40000-1-2 draft from the European Committee for Electrotechnical Standardization.

We will start by defining the product's context and defining risk acceptance criteria. Then, we will move to the risk assessment itself. This involves finding and documenting the product's assets and objectives, identifying threats, estimating how big the risks are, and then evaluating the risks to process them further.

To close the risk management loop, we will discuss how to treat risks, how we need to communicate risks to our users and how to monitor and review those identified risks.

The implementation of the EU Cyber Resilience Act is currently shaped by two flawed assumptions: that most open source projects have a steward, and that stewards are synonymous with foundations. Data from the JavaScript and Rust ecosystems shows the opposite—hundreds of thousands of widely used packages exist outside any stewardship structure, while foundations oversee only a tiny fraction. The CRA anticipated this reality and introduced a separate mechanism to help manufacturers meet due-diligence requirements: a security attestation program intended to function as an open-source analogue to CE marking. Done well, attestations can dramatically simplify compliance while improving security and sustainability across the ecosystem.

Current proposals, however, lean toward lightweight models that offer limited value to manufacturers and little support for the maintainers who produce the software those manufacturers rely on. This talk proposes a more effective middle path: an attestation approach that leverages maintainer expertise, delivers clear and actionable assurances to manufacturers, and creates sustainable revenue channels for projects.

Using the OpenJS Foundation’s Ecosystem Sustainability Program (ESP) as a concrete example, we will illustrate how project-approved commercial support, revenue sharing, and clear integration points can produce benefits for both manufacturers and maintainers. ESP demonstrates how a structured program can help fund essential security and maintenance work without requiring projects to become foundation-stewarded. By connecting these lessons to the CRA’s attestation framework, the session outlines what a truly useful attestation system could deliver: practical compliance for manufacturers, meaningful support for maintainers, and a healthier, more resilient open source ecosystem.

Everyone's building CRA compliance tooling: SBOM generators, vulnerability scanners, security scorecards, automated due diligence checks. But, CRA readiness isn't just about tooling. It's about ensuring the data feeding those tools is actually accurate and trusted. The project activity, package metadata, licensing information, and vulnerability data these tools depend on is systematically unreliable, and we need to fix it at the source.

This talk demonstrates why data accuracy is the blocking issue for practical CRA readiness. We'll show real-world examples from major package ecosystems: Python packages with wrong license declarations, Java JARs with embedded vulnerable dependencies that scanners miss, Rust crates with incomplete origin metadata. When demonstrating due diligence or attempting automated vulnerability reporting, the underlying data failures make compliance impossible, no matter how good your tools are.

The good news is that this is solvable, and the FOSS community is already working on it!

We'll present concrete approaches being deployed across ecosystems: systematic metadata curation projects that scan and fix package data at scale, validation tooling that catches errors before publication, and community infrastructure that makes accurate software metadata freely available. You'll see how projects like Maven Heaven, T-Rust, and Nixpkgs Clarity are cleaning up metadata for the most popular packages, releasing curated data under open licenses, and providing author-facing tools to prevent bad data from entering registries. And we'll discuss how reliable project health data provides critical insights for proactive CRA due diligence and risk management.

This session gives you practical next steps: how to audit data quality in your dependencies, contribute to metadata curation efforts, integrate validation into your publishing workflow, and leverage community-curated data for more reliable compliance automation.

For FOSS maintainers, many of whom contribute voluntarily and without formal organizational backing, the CRA raises urgent questions: What exactly changes for my project? What responsibilities - if any - apply to me? And how can I prepare without being overwhelmed? This panel puts FOSS maintainers at the center of the conversation. Joined by industry practitioners for complementary perspectives, maintainers will discuss what the CRA means for day-to-day project work, long-term sustainability, and collaborative development practices. Key topics include: Which CRA obligations might touch volunteer-driven FOSS projects - and which clearly do not What are those tools you use right now or plan using to get closer to the CRA readiness and what you’re missing How maintainers can proactively position their projects without needing formal compliance How industry stakeholders can step up to support the FOSS components they rely on Practical guidance on documentation, secure development practices, and project governance How the CRA could catalyze a healthier relationship between FOSS communities and commercial users

When a kernel component like a storage driver misbehaves in production, developers face a difficult choice. They either have too little information to solve the bug or they enable slow console-level debug logs that ruin performance. This talk introduces a per-component binary logging mechanism designed to support verbose logging in production with negligible run-time cost.

We achieve this efficiency by moving the heavy lifting to build time. using preprocessor macros, we emit parameter serialization stubs and save location-specific formats in a separate side table. At run time, the hot path only records a location ID, a timestamp, and the raw parameters. No format expansion occurs until the logs are read. We support high concurrency using a mostly lock-free multi-level allocator that allows dozens of CPUs to write simultaneously.

We also introduce a significant architectural change by adding a single TLS pointer to struct task_struct. This tags each thread with a private logging buffer. If a thread stalls or deadlocks, the tag remains attached to the buffer. This allows post-mortem analysis to reveal the exact context-specific history of that thread.

Unlike ftrace_printk which dumps everything into a single global ring, our logger maintains one ring per component context. This allows you to capture exactly the data you need for a specific file system or operation. The memory footprint is minimal. Each record is only eight bytes. This saves 16 bytes per entry compared to the standard bprint_entry. This efficiency reduces memory accesses and facilitates a truly production-ready binary logging infrastructure.

We can finally keep verbose logging active at all times. This ensures that when a crash or deadlock occurs, the high-fidelity history needed to solve it is already waiting in memory.

For years, Ahmad’s ideal has been simple: unpack a rootfs on a server, mount it over NFS (or usb9pfs), boot directly into it, and everything just works™.

But as secure boot becomes the default on many embedded systems, squeezing in a network-booted kernel is getting harder and often falls outside the supported boot flow entirely.

Fortunately, some recent improvements in the kernel build system pave the way for a far less invasive netboot setup. This talk gives a quick tour of the key pieces:

• The image.fit target for arm64 introduced in v6.10
• The modules-cpio-pkg target introduced in v6.19
• Initramfs that bind mounts its modules over the rootfs
• Optional concatenation of multiple initramfs in the bootloader

In ten minutes, you’ll see how these changes raise the netboot FITness of Linux, so you can keep printk-debugging to your heart’s content.

The linux kernel driver model has grown over the years and acquired several different mechanisms for passing device configuration data to platform drivers. This configuration can come from firmware (device-tree, ACPI) or from the kernel code itself (board-files, MFD, auxiliary drivers).

For a less experienced driver developer, the different APIs that are used to access device properties can be quite confusing and lead to questions: should I use the OF routines? Maybe fwnode or the generic device properties? What are software nodes in this model and what even is a device property? How are devices linked according to their provider-consumer relationship and their probe order ensured, if at all?

This talk will discuss the history and evolution of device properties - from legacy, custom platform data structures, through the introduction of the open-firmware API and its generalization to firmware nodes alongside other fwnode implementations up to the generic device property API. It will also touch on the devlinks and how they tie into this model.

The goal of this beginner/intermediate level talk is to give a clear picture of how device configuration should be handled in the kernel.

A new RFC for Netfilter/nftables arrived recently in the netfilter-devel mailing list [1], introducing flexible math operation support for network packet fields. This could solve some migration problems from iptables to nftables and in addition empower other use-cases.

This demo will quickly show how it works with simple real-world scenarios.

[1] https://lore.kernel.org/netfilter-devel/20250923152452.3618-1-fmancera@suse.de/

Tracing complex systems often requires insights from both the kernel and userspace. While tools like Linux's ftrace excel at kernel-level observability and LTTng provides low-overhead userspace tracing, unifying these disparate data sources for a holistic view remains a challenge: using LTTng for kernel tracing requires an out-of-tree kernel module, which can be a barrier for many users.

This talk introduces bt2-ftrace-to-ctf - a new open-source project designed to bridge this gap. Our solution processes a trace.dat file from ftrace (kernel part) and a LTTng UST for userspace, then aligns and rewrites the trace in the Common Trace Format (CTF), as used by LTTng. The resulting output is directly consumable by tools like Trace Compass, enabling comprehensive, synchronized analysis of system behavior across all layers without the need for custom kernel modules.

The project consists of two key components:

• A Babeltrace2 plugin: This plugin allows babeltrace2 to directly read trace-cmd's trace.dat files, providing a standardized interface for ftrace data. It includes source and sink components for flexible data handling and metadata emission.
• A trace.dat to CTF converter: This utility utilizes the Babeltrace2 plugin to transform ftrace data into an LTTng-alike kernel trace in CTF format. Crucially, it can also combine this kernel trace with an existing LTTng userspace trace, producing a single, unified trace directory.

In the talk, we will give an overview on the tool and discuss challenges during its implementation.

Project: https://github.com/siemens/bt2-ftrace-to-ctf (MIT, LGPL-2.1-or-later)

Creating filesystem images typically requires mounting, copying files, and hoping your build environment doesn't introduce non-determinism. New capabilities in mkfs.xfs solve both problems. You can now populate an XFS filesystem directly from a directory tree at creation time, no mount required. I'll cover the implementation approach, discuss design, and show how to use it. Useful for distributions, embedded systems, and anyone who needs verifiable filesystem artifacts.

Reference commits: https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?h=for-next&id=8a4ea72724930cfe262ccda03028264e1a81b145

https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?h=for-next&id=4a54700b4385bbedadfc71ee5bb45b0fc37fabb7

Correctness of operating system kernel code is very important. Testing is helpful, but does not always thoroughly uncover all issues. In the Whisper team at Inria, we are exploring the possibility of applying formal verification, using Frama-C, to Linux kernel code. This entails writing specifications, constructing loop invariants, and checking correctness with the support of a SMT solver. This talk will report on the opportunities and challenges encountered.

Most SoCs provide a PWM controller which it used mainly to drive LEDs, a display backlight or a fan. Less often a PWM controls a motor.

The motor use case has a higher demand for exact control of the produced output. In the development cycle for Linux 6.13, the preferred abstraction for a PWM driver changed to be able to fulfill these needs.

After a quick introduction about what a PWM actually does, Uwe (who is also the Linux PWM subsystem maintainer) will present the new API with its requirements and the hardware and software he uses to develop and test a driver.

Sheaves are a new percpu caching layer for the SLUB allocator. To some extent it's a return to the SLAB percpu arrays (and magazines in the original Bonwick's paper), but avoiding the pitfalls of the SLAB implementation, attempting to get the best of both SLAB and SLUB approaches.

In 6.18 sheaves were merged and enabled for maple node and VMA caches. There's ongoing work to fully convert all caches in 7.0. This talk will discuss the status, explain the tradeoffs involved and present some results and lessons learned.

This talk is a follow-up for LPC 2025 "seccomp listeners for nested containers" from "Containers and Checkpoint/Restore" MC [1].

I'll give an update of patch-set progress in LKML, overview of technical challenges. In case if it is merged upstream by the time of this talk at FOSDEM, I'll show a demo of this feature and give a detailed overview of implementation and potential future improvements.

[1] https://lpc.events/event/19/contributions/2241/

TPMs have been present in modern laptops and servers for some time now, but their adoption is quite low. While operating systems do provide some security features based on TPMs (think of BitLocker on Windows or dm-verity on Linux) third party applications or libraries usually do not have TPM integrations.

One of the main reasons of low TPM adoption is that interfacing with TPMs is quite hard: there are competing TPM software stacks (Intel vs IBM), lack of key format standardization (currently being worked on) and many operating systems are not set up from the start to make TPM easily available (TPM device file is owned by root or requires privileged group for access). Even with a proper software stack the application may have to deal with low-level TPM communication protocols, which are hard to get right.

In this presentation we will explore a better integration of TPMs with some Linux Kernel subsystems, in particular: kernel keystore and cryptographic API. We will see how it allows the Linux Kernel to expose hardware-based security to third party applications in an easy to use manner by encapsulating the TPM communication complexities as well as providing higher-level use-case based security primitives.

The basic concept of Secure Boot is now well established (and widely used in Linux for nearly 15) years. Most people now decline to take ownership of their systems (by replacing the CA keys in the UEFI db variable) and instead pivot trust away from the UEFI variables to the MoK (Machine Owner Key) ones instead, which can be updated from the operating system. Thus if you want to secure boot your own kernel, you usually create a signing key and load that into MoK.

This talk will go quickly over the history, how you take ownership, what problems you encounter, how you create and install your own signing keys in MoK and how the kernel imports all these keys into the keyring system and uses them (verifying module signatures and IMA signed policy) including the differences betwen the machine and secondary_trusted keyrings. We'll also discuss some of the more recent innovations, like adding SBAT to the rather problematic UEFI revocation story and how it works.

Usermode Linux (UML) has been developed and maintained in linus tree for decades and well used by kernel developers as an instant way of virtualization within userspace processes, without relying on hypervisor (i.e., qemu/kvm) or software partition (i.e., namespace). Recently unit testing framework for kernel tree, KUnit, bases UML as an underlying infrastructure for the framework, which brings us more opportunities to use UML. However, this testing capability of KUnit+UML is currently limited to MMU-full codebase where there are certain portion of code with ifndef CONFIG_MMU in the kernel tree. As a result, nommu code lacks the chance of testability and often introduces regressions in the rapid development cycle of linux kernel.

This talk introduces yet-another extension to UML, based on the architecture without MMU emulation, in order to exercise nommu code with a plenty of testing framework implemented on KUnit+UML . The kernel is configured with the option CONFIG_MMU=n, and we've implemented a different syscall hook and handling mechanisms with the different interactions to the host processes. With that, existing userspace programs (we've used Alpine Linux image with patched busybox/musl-libc) can run over this UML instance under nommu environment. As a bonus using different implementation to the host interactions, we got speedups in several workloads we've tested including lmbench and netperf/iperf3 benchmarks.

I will briefly overview its implementation, the comparison with the original UML architecture, and share several measurement results obtained during the development. We will also share the upstreaming status which we have been proposed [*1].

*1: https://lore.kernel.org/all/cover.1762588860.git.thehajime@gmail.com/

At Chainguard, we want to re-use binary objects across Linux kernel builds of different major versions. For us this is useful for FIPS certification of individual kernel components while still allowing us to build new kernels and not pin the entire kernel forever. To achieve this, we performed a number of experiments with the kernel build system and spoke to other kernel developers about their efforts to achieve the same thing. I will discuss approaches to re-using binary objects, the limits of each, and how the linux kernel could have a stable(r) ABI.

In this session we're going to take a look at new developments in the VFS layer and related areas.

This live demo shows how to pick a real syzbot-reported bug and reproduce it locally in under five minutes using virtme-ng. No disk images, no complex QEMU setup—just build, reproduce and verify the fix. Perfect for anyone who wants to turn kernel fuzzing reports into real patches. Important note: I am going to use pre-built upstream kernel containing a bug due to the talk time constarins. Hovewer, steps to rebuild an upstream kernel and use it in virtme-ng will be described.

Full Description: syzbot continually discovers kernel issues, but reproducing them can be slow or intimidating. In this lightning talk, we’ll use virtme-ng to rebuild a mainline kernel and instantly run a real syzbot reproducer inside an ephemeral VM. We’ll trigger the crash, inspect the backtrace, apply the upstream fix, and rerun the test to verify the resolution—all live. This workflow reduces setup time from hours to minutes and lowers the entry barrier for new contributors. Every attendee will leave knowing how to reproduce syzbot bugs safely and efficiently on their own system.

Live Experiments & Demonstrations:

• Select an active syzbot issue (syzbot.appspot.com) and show its reproducer.
• Build a mainline kernel and launch it via virtme-run --kdir . --repro repro.c.
• Trigger the crash and display kernel backtrace.
• Apply the upstream patch or manual fix.
• Re-run the reproducer and verify crash disappearance.

Key Points:

• Use virtme-ng for instant kernel test environments.
• Run real syzbot reproducer without manual QEMU setup.
• Observe, patch, and verify kernel bugs live.
• Encourage new contributors to validate fuzzing results.
• Demonstrate a fully reproducible workflow in < 5 minutes.

This talk follows last year's presentation "Status and Desiderata for Syscall Tracing and Virtualization Support" and reports on progress and remaining gaps in Linux system call tracing.

The talk presents a set of Linux kernel patches, intended for upstream submission, that address the following limitations and aim to make system call tracing and virtualization more expressive, portable, and efficient.

Over the past year, support for PTRACE_SET_SYSCALL_INFO has been merged into the mainline kernel. While developing a portable version of VUOS across multiple architectures, several limitations of the current tracing interfaces became evident. In particular, skipping a system call by setting its number to -1 is insufficient, as it does not allow the tracer to control the return value or errno, nor to adjust the program counter. As a consequence, the current VUOS proof-of-concept replaces skipped system calls with getpid and fixes up the return value at PTRACE_SYSCALL_INFO_EXIT, doubling the number of context switches and incurring a measurable performance cost. Updating the program counter currently requires non-portable, architecture-specific code using PTRACE_POKEUSER or PTRACE_SETREGSET.

Additional issues arise with seccomp_unotify. Tracing all system calls is difficult because file descriptors must be transferred from the traced task to the tracer; common techniques based on UNIX domain sockets and ancillary messages require sendmsg and recvmsg themselves to be excluded from tracing. Furthermore, there is currently no support for virtualizing the F_DUPFD command of fcntl, nor for allowing a tracer to atomically close a file descriptor in the traced process.

Power saving has always been a major preoccupation in embedded systems, as by definition, they could have energy constraints. As embedded systems become increasingly pervasive, from IoT devices to industrial controllers, power efficiency is more critical than ever. This talk is aimed at developers, system integrators, and Linux enthusiasts. Whether you’re optimizing a battery-powered board or a power sensitive industrial board, you’ll walk away with practical insights and actionable tools. This talk will explore how to reduce electrical consumption on an embedded Linux system by leveraging software techniques such as kernel low power state (Suspend-To-RAM, Suspend-To-Disk), devices management. We’ll cover how to disable unused peripherals or scale CPU frequencies

Upstreaming kernel support traditionally happens only after silicon becomes available, but this approach often delays software enablement and ecosystem readiness. For the first time in the RISC-V world, we are tackling the challenge of pre-silicon kernel upstreaming—enabling Linux kernel features ahead of actual chip availability. In this session, we will share the methodology, toolchains, and collaborative workflows that make this possible, including the use of simulation platforms, pre-silicon verification environments, and CI/CD integration for early kernel testing. Attendees will learn how these efforts accelerate software-hardware co-design, reduce bring-up cycles, and ensure that by the time silicon arrives, the kernel is already upstream-ready. This pioneering approach not only shortens time-to-market but also sets a new model for open source hardware-software collaboration in the RISC-V ecosystem. Key Takeaways: - Why pre-silicon kernel upstreaming is a game-changer for RISC-V. - The tools and processes used to validate and upstream before silicon. - Lessons learned and best practices for collaborating with the open source community.

So here's the deal: if you want to tag a packet (sk_buff) with some info that actually sticks around as it travels through the Linux network stack, your only real option right now is a measly 32-bit SO_MARK field. That's not a lot of room, and everyone's fighting over those bits. In this talk, we'll share Cloudflare's quest to get 128+ bytes of metadata attached to packets—enough space to do cool stuff like keeping config consistent across network layers, classifying packets in XDP, and figuring out exactly why a packet got dropped.

We've been at this for a while, and we'll walk you through the three main chapters of our journey—the dead ends, the duct tape solutions, and what we think might actually work:

Part One: SKB Traits. Remember that per-packet key-value store idea called "SKB Traits"? We'll tell you why we got excited about it and why we eventually tossed it out in favor of not having a second metadata area.

Part Two: XDP Metadata. Next up, we tried piggy-backing on skb->data_meta and brought in bpf_dynptr to wrangle the metadata. Spoiler: it gets messy. L2 tunnels and pulling packet headers can leave your metadata corrupted or just plain gone. We'll dig into our attempts to untangle metadata tracking from MAC header offsets and the backward compatibility headaches that come with it.

Part Three: SKB Extension. Finally, we'll show you our latest idea: using sk_buff extensions (skb_ext) backed by BPF local storage. The nice thing here is that metadata lives separately from packet headers. But we're not out of the woods yet—memory allocation on the hot path is still an open problem.

Cluster orchestrators such as Kubernetes rely on an accurate model of the resources available on each worker node in a cluster and on the resources a given job requires, using this information to place the job onto a suitable worker node in the cluster. If either is inaccurate, the orchestrator will make poor job placement decisions, resulting in poor performance.

I observe that Linux kernel scheduling overheads can, for workloads making heavy use of Linux's group scheduling (cgroups) which include common serverless workloads, become so significant as to make the orchestrator model of worker node resources inaccurate. In practice this effect is mitigated by over-provisioning the cluster.

I propose and evaluate an enhancement to the Linux Completely Fair Scheduler (CFS) that mitigates these effects. By prioritising task completion over strict fairness, the enhanced scheduler is able to drain contended CPU run queues more rapidly and reduce time lost to context switching. Experimental results show that this approach can deliver equivalent performance using up at least 10% fewer worker nodes, significantly improving cluster efficiency.