Planet CCC - Blogs and more around CCC, CCC-Hamburg and Attraktor

What if we could run systemd services on top of virtual cpu/memory, to get hypervisor/cpu protection of memory pages? Demo of a very much work-in-progress proof-of-concept Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/7U77A3/

Video:asg2026-448-eng-systemd_services_as_microvms_sd.mp4

What's new in zbus https://zeenix.github.io/presentations-marp/LTs/zbus-6-whats-new.html Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/3C8PUC/

Video:asg2026-447-eng-zbus_60_sd.mp4

At Axis, we are always interested in standard technologies and how we can align with them. With that in mind, we have been studying the principles and ideas behind ParticleOS. In this session, we will build ParticleOS live with mkosi and boot it in a VM. We will look into the provisioning steps of such a machine and the changes in the OS image layout. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/L3KZRV/

Video:asg2026-445-eng-ParticleOS_in_action_sd.mp4

System extensions (sysexts) become part of the host's /usr, making them available to all users. But what if we want to run tightly coupled services without exposing their binaries to everyone else on the system? This lightning talk will show how to ship a real-world stack (kubelet, containerd, and runc) without making them accessible to the rest of the host. We will demonstrate how to use portable services and systemd capsules to allow these components to invoke each other and share some namespaces, all while keeping the host OS clean. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/K9GPKV/

Video:asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_sd.mp4

Recently systemd acquired functionality to download & invoke OCI containers directly. In this talk I'd like to explain where we are at with this, what we have, where the gaps are and where we are going, to make OCI containers a thing you can directly execute with systemd, without external tools. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BWWVCN/

Video:asg2026-435-eng-systemd_OCI_sd.mp4

In recent systemd releases we substantially improved the tooling for provisioning and deploying operating systems with systemd. For example, systemd-sysinstall, systemd-sysupdate, credentials, systemd-firstboot, systemd-stub's parameterization logic, systemd-confext, systemd-imds, systemd-import all are relevant components for getting a node up and running with the right configuration, securely and robustly. In this talk I'd like to explain the current landscape, and how the various components matter in various scenarios, and how they fit together. I'll also discuss what's next, what's missing, and where we should be going with all this. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/NLRDPH/

Video:asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_sd.mp4

The limitations of systemd-sysext/confext from the early days are mostly gone nowadays. The loading of extension images from the initrd means that generic content will behave as expected without any workarounds. New settings help making live reconfiguration work better as well. We will see how declarative configuration management with systemd-sysext/confext from git can be done with an OpenTofu/Terraform module. For image-based Linux binding configuration together with a pinned OS version is now possible through bootctl link. OS builders can ship /etc files through a default confext image. systemd-sysext/confext: https://www.freedesktop.org/software/systemd/man/devel/systemd-sysext.html bootctl: https://www.freedesktop.org/software/systemd/man/devel/bootctl.html Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/RMC879/

Video:asg2026-429-eng-An_update_on_systemd-sysext_confext_sd.mp4

Systemd can now be linked as a single static binary, which is enough to run a "full system" container that boots into a running manager. Transient units can then be used to do more things in the container. Thanks to systemd-nsresourced and systemd-mountfsd, this now works fully unprivileged and with no suid helpers. I want to show that this actually works and can be used for experimentation, development, and custom container images. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/XU9CJR/

Video:asg2026-427-eng-single-file_containers_with_statically_linked_systemd_sd.mp4

For a while, the standard way to run Podman containers under systemd was podman generate systemd. It worked, but the output was static and awkward to maintain. Quadlet replaced it — and most guides stop at "drop an INI file in a directory and your container starts." leaving the machinery a black box. This talk demystifies that black box, because the internals are exactly what you reach for when things break. Quadlet isn't a daemon. It's a systemd generator that runs at daemon-reload and turns your .container, .pod, and .network files into ordinary .service units. In session, we'll trace one stack example from end to end, watching a three-line container file expand into a full podman run command, and cross-unit references become injected After=/Wants= dependency edges with name-mangled volumes and networks. You'll leave knowing exactly what gets generated, why edits need a daemon-reload, how to dump & debug a failing unit yourself, and explain why keeping only the source files under version control is reliable. Less magic, more model. Quadlet isn't magic—it's a systemd generator. Watch a three-line .container file expand into a full service unit, and learn to dump, debug, and reason about what really gets generated. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/PXBVLE/

Video:asg2026-424-eng-Forget_podman_generate_systemd_How_Quadlet_Really_Works_sd.mp4

Using mkosi and apparmor.d as building blocks, this talk presents a prototype minimal Debian server. The goal is not to provide yet another Linux distribution, but to explore how hard it is to build personalized, hardened server images. On top of the usual mkosi-backed features such as UKIs, A/B updates and dm-verity, the project adds a whole-system AppArmor policy and an immutable `/etc`. Because older devices also matter, the prototype supports the Raspberry Pi 3 (UEFI) too, with minor changes to the security model. The talk presents the differences in design, attacker model, and implementation between the various targets. This talk walks through a prototype: a minimal, hardened Debian server built with `mkosi` and `apparmor.d`. It composes three layers of systemd and Debian tooling that are well understood alone but rarely combined, each reinforcing the others: - **Image-based OS:** `mkosi` magic. - **Whole-system MAC:** AppArmor policies that confine every process on the system. It also brings: - Multi-layered policy loading, fixing the AppArmor load-time issues that hurt small devices. - Immutable security policies. - Compatibility with systemd sysext/confext. - **Immutable `/etc`:** assembled from signed `systemd-confext` images, closing immutability's usual escape hatch. The same image targets both an x86-64 server and a Raspberry Pi 3 (UEFI), and that contrast is where it gets interesting. The two share a single build but diverge on attacker model and security guarantees: what an embedded device with no Secure Boot can promise versus a server, and where the implementation has to bend. We walk those differences, the limitations, and what would have to land upstream to make this kind of image easier. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/KJNYQ8/

Video:asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_sd.mp4

Observability stacks have gotten good at CPU, memory, and network — but storage is still where the picture goes dark. When a workload stalls on I/O, device-level tools like iostat or blktrace tell you the disk was busy; they don't tell you which service caused it, or where in the stack the latency actually accrued: a slow fsync, writeback pressure in the page cache, a filesystem journal commit, or a saturated block queue. This talk follows a single write from the syscall boundary down to the block layer, using eBPF to instrument each handoff — VFS, the filesystem, the page cache, and block I/O submission and completion — without patching applications or running a custom kernel. We'll look at which attach points (tracepoints, fentry/fexit, kprobes) give honest per-layer latency, how to keep the measurement overhead from biasing the result, and how to attribute the latency back to the responsible cgroup or systemd service instead of an aggregate line on a dashboard. Examples range from fsync-heavy database commits to large sequential writes that look fine at the device level but stall well above it. Attendees will leave with a concrete method for turning storage from a black box into a traceable path — and an honest sense of where eBPF helps, and where it still can't see. Follow a single write from syscall to block layer with eBPF, measuring honest per-layer latency at each handoff and attributing storage stalls to the service that caused them. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/XHJX3N/

Video:asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_sd.mp4

Immutable, image-based Linux has gone mainstream — on Fedora. Nearly every atomic distro descends from the RPM/ostree lineage. Debian is conspicuously rare, with really only Vanilla OS and Endless OS to its name. There's a reason, and it's apt: Debian's package manager expects a writable root filesystem, so the moment you seal the rootfs, the native way to install and update software stops working. That's the wall every immutable Debian hits, and most climb it with Flatpak or containers. This talk takes a different route — Nix. Nix keeps everything in a self-contained, content-addressed /nix/store, so it never needs a writable rootfs. The base is built once with mkosi and frozen (apt isn't even installed) and Nix manages everything that changes after that, reproducibly. The result is an immutable Debian rootfs with the entire Nix package ecosystem available on top. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BEDGKF/

Video:asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_sd.mp4

IETF is standardizing a new ACME challenge, `device-attest-01`, which allows organizations to provision device bound certificates to machines, and enables machines to present signing certificates that can't be extracted out of machines they where intended for. This is useful for cases where you want to provide reverse proxies with mTLS with a strong sense of device identity. attezt is intended to be a suite of tools to work the new `device-attest-01` ACME challenges for Linux. It provides an ACME client, an attestation server with (simple) support for inventory systems and a PKCS11 agent which together enables the support of this ACME challenge on Linux. This talk will give an introduction to the new ACME challenge, a quick rundown of how an attestation server works and how attezt works. https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ https://github.com/Foxboron/attezt Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/8XRBTA/

Video:asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_sd.mp4

The image based Linux vision is clear: immutable system images, declarative composition, no imperative package installation at runtime. But what happens when you need dozens of independently deployable application modules on the same device, each owned by a different team in a large enterprise, each on its own release cadence, while keeping the root filesystem untouched? We built a modular deployment system for production Linux devices that takes the image based philosophy to its logical conclusion: every module is a read only ext4 filesystem image, built deterministically at build time, deployed to its own A/B partition with zero installation, and managed entirely through systemd transient services. No unit files on the rootfs. No package manager on the device. No post deploy scripts. The image is the truth. On the packaging side, we use deterministic ext4 creation with constant timestamps to produce (mostly) reproducible images regardless of build environment. This reproducibility directly enables efficient delta based OTA: because the on device image is read only and byte identical to what was built, we can chunk-diff against it and deliver only changed blocks critical for constrained networks. On the runtime side, a oneshot service mounts each module and starts it via systemd-run as a transient service inheriting automatic restart, cgroup resource control, and clean lifecycle semantics without ever writing a .service file to disk. We deliberately rejected the alternative of modules shipping their own unit files precisely because it violates the principle that deployment must not modify the root filesystem. Transient services give us the systemd machinery we need while preserving an immutable rootfs compatible with dm-verity. Modules are fully isolated: separate uid/gid, sandboxed filesystem access, dedicated persistent storage, and communication exclusively through a formal interface (gRPC unix domain sockets in our case). Each module treats every other module as a remote server: no hard startup dependencies, no shared state, no assumption that any other module is even present on the same device The talk will cover: * Applying image based Linux principles at the application module level, not just the OS * Packaging modules as (mostly) reproducible, read only ext4 images with deterministic tooling * How image based module packaging enables per-module automated testing: deploying test harnesses as modules themselves, composing versioned module sets for deterministic integration testing, and unlocking independent CI/CD pipelines per team * Why deb/rpm, Flatpak, and AppImage each fail for independently deployable A/B modules * Delta-based OTA delivery that exploits immutable images for chunk-level diffing * systemd transient services as a module lifecycle manager: all the benefits of systemd, none of the rootfs side effects * Per-module sandboxing, cgroup isolation, and gRPC-only IPC * Lessons from production: independently updating 40+ modules without device reboot Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/VLKVKW/

Video:asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_sd.mp4

When you lock your systemd-homed enabled Linux desktop today, your home directory (including the desktop session) is fully frozen. This happens because systemd-homed uses a single cryptographic key (the LUKS volume key) and throws it away during lock. Want to lock away just your credentials as on a normal screen lock while keeping music playing and notifications coming through? You can't. This talk presents the work done as part of the systemd STF grant to extend the systemd-homed's key hierarchy that fixes this issue. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/TL3KGN/

Video:asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_sd.mp4

The storage directory settings in systemd help define where services store their data. Two important features have been implemented for these directories. The first one is id-mapped mounts, which is a filesystem feature that allows a mount namespace to show a different UID than what is stored on a file. Storage directories now support id-mapping, so that the files within the mount namespace of a service defined with DynamicUser=yes are owned by its unprivileged UID/GID. The second feature is storage quota support. Storage limits can now be defined in terms of percentages or absolute values to enforce quotas on the consumption of State, Cache, and Logs directories. These features enhance the security and resource management of systemd services. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/N93KWW/

Video:asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_sd.mp4

The Yocto project contains multitudes, and as such it contains the ability to create a modern, image based, integrator friendly operating system, taking advantage of various layers of tooling for hardware and feature support. Moonforge is the result of the work done by Igalia in this space, and it focuses on making it easy to create, build, test, deploy, and update a OS image for multiple products and verticals. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/HNUWBK/

Video:asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_sd.mp4

Systemd provides a growing set of very useful varlink APIs. With the new Rust-based varlink-http-bridge, it is possible to expose any number of them over the network securely via https/websockets, including over vsock, with all of the interesting varlink features like "more" support or "protocol-upgrade" support. This presentation gives an overview of why varlink and websockets are such a good fit, why the varlink-http-bridge implementation is mostly just a transparent byte proxy, and how it plugs into varlinkctl seamlessly to make networked varlinkctl calls "just work". It also explains the security model and the plans for the future. The project lives in https://github.com/systemd/varlink-http-bridge. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/WDRTYW/

Video:asg2026-407-eng-Bridging_the_varlink_gap_sd.mp4

Linux doesn't have a unified way to be installed. Every distribution implements their own installer with a different feature set and UX. systemd-sysinstall is a tool to install an OS to a device. It leverages repart to format the disk and bootctl to manage UEFI and the boot partition and supports disk encryption and TPM integration. In addition, it exposes a varlink interface to be used by graphical installers. In this talk we will explore what sysinstall does, how the GNOME OS installer (gnome-setup) leverages it to install GNOME OS, why distributions shipping GNOME should switch to gnome-setup, and how other desktop environments can build installers using the same stack. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/SBUXXA/

Video:asg2026-404-eng-A_unified_OS_installer_in_systemd_sd.mp4

sdme is a single static binary that boots systemd-nspawn containers using copy-on-write roots (overlayfs layers or btrfs snapshots), with OCI registry pulling and Kubernetes Pod YAML support. No daemon, no runtime dependency beyond the systemd you already run. Why I built it. Every container runtime reinvents what systemd already does well: process supervision, logging, cgroups, service ordering, socket activation. sdme makes the opposite bet. systemd-nspawn already boots a full system in isolation; the kernel already gives it a cheap copy-on-write root, whether through overlayfs or a btrfs snapshot. Put a thin, daemonless CLI over the two and you get container workflows (clone, import, pull, run) without a new runtime to install or a daemon to keep alive. It began as a one-command clone of the running host, but the bet is bigger than that: lean on the init system instead of rebuilding it. What you get. Proper machine-like containers: each one runs a full systemd init with journald, D-Bus, and systemctl, not a single foreground process. Each container is highly configurable through native systemd surfaces, with per-container resource limits, networking, and drop-in config. Clone your running host into a throwaway container in one command; run a Docker Hub image (nginx, redis, postgres) as a managed systemd service instead of a foreground process; deploy a multi-container pod from Kubernetes Pod YAML with health probes, secrets, and configmaps. A rootfs can also come from any distro, an OCI registry, a tarball, or a QCOW2 image, and you can build your own from a Dockerfile-like config. How it works. One copy-on-write root and one systemd-nspawn invocation give you a fully booted system. Storage is pluggable per container. The overlayfs backend mounts the host / (or any imported rootfs) as an immutable lower layer with a fresh upper, so clones are instant. The btrfs backend snapshots the base rootfs as a subvolume instead, which makes the container root a real filesystem: nested containers work, user namespaces use native idmapped mounts, and per-container disk quotas come from qgroups. It runs directly on a btrfs data directory, or inside a loopback pool image on any other filesystem. The binary does two jobs: it manages those copy-on-write roots, and it drives systemd over D-Bus to start, stop, and supervise containers. Everything else (init, journald, cgroups, service ordering) is systemd doing what it already does, with no daemon in the middle. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/E7MHZJ/

Video:asg2026-403-eng-Containers_without_a_new_runtime_sdme_on_systemd-nspawn_sd.mp4

Marco will review the state of systemd sandboxing in Debian packages, what we need to fix to have more and what will break by enabling too much of it. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/VLBXZ8/

Video:asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_sd.mp4

Recent years have spurred much discussion in Linux communities about the idea of building an OS that is both Trusted and Immutable. While successful in many ways, attempts to implement these ideas have created numerous sharp edges for end users. At the same time, these initiatives bear many advantages for the ecosystem's push towards becoming more reliable, accessible, and consumable. What lessons can we take from other OS vendors to improve user experience and accelerate adoption? Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/R8XMRT/

Video:asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_sd.mp4

User space based Full Disk Encryption in openSUSE is old news. We already can set up FDE installations using the systemd toolset. This allows us to use traditional passwords, the TPM2 to validate the status before mounting the encrypted device or a FIDO2 key to validate the presence of a token owned by authorized users. To increase the security, in Tumbleweed, we recommend combining both TPM2 and a password (TPM2+PIN). This guarantees the system is in a healthy state and the user has the correct authorization, but it still doesn't support a combination of TPM2 and FIDO2 keys. To fix this issue, we are proposing a new enrollment method in systemd: TPM2+FIDO2. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/SD3X9L/

Video:asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_sd.mp4

This talk will present the newest updates and advancements in NixOS related to Secure & Measured Boot. It will take a look at what we have achieved this far, what issues we have come across, what we would like to see from the ecosystem, and what we are working towards next. Additionally, it will go over some other exciting things that happened related to systemd in NixOS. Key advancements: - [Support for Measured Boot via systemd-pcrlock in Lanzaboote](https://github.com/nix-community/lanzaboote/pull/564) (the boot security toolkit for NixOS) - [Support for Boot Counting in Lanzabooote](https://github.com/nix-community/lanzaboote/pull/477) - [Removed most patches from systemd (18 -> 6)](https://github.com/NixOS/nixpkgs/pull/488508) and added a patch policy that prohibits most new patches. - [systemd initrd is now the default](https://github.com/NixOS/nixpkgs/pull/435781) Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/QDB7AL/

Video:asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_sd.mp4

Let's have an open discussion with systemd developers who are at ASG and users in the audience. We will open with the developers saying what they plan to work on in the near future, and then allow questions / comments from the audience. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/RN9E3E/

Video:asg2026-390-eng-systemd_round_table_sd.mp4

Same as every year, a lot has happened in the systemd project since last year's ASG. We released multiple versions, packed with new components and features. This talk will provide an overview of these changes, commenting on successes and challenges, and a sneak peak at what lies ahead. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BTLLGC/

Video:asg2026-389-eng-systemd_state_of_the_project_sd.mp4

What if we could run systemd services on top of virtual cpu/memory, to get hypervisor/cpu protection of memory pages? Demo of a very much work-in-progress proof-of-concept Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/7U77A3/

Video:asg2026-448-eng-systemd_services_as_microvms_hd.mp4

What's new in zbus https://zeenix.github.io/presentations-marp/LTs/zbus-6-whats-new.html Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/3C8PUC/

Video:asg2026-447-eng-zbus_60_hd.mp4

At Axis, we are always interested in standard technologies and how we can align with them. With that in mind, we have been studying the principles and ideas behind ParticleOS. In this session, we will build ParticleOS live with mkosi and boot it in a VM. We will look into the provisioning steps of such a machine and the changes in the OS image layout. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/L3KZRV/

Video:asg2026-445-eng-ParticleOS_in_action_hd.mp4

System extensions (sysexts) become part of the host's /usr, making them available to all users. But what if we want to run tightly coupled services without exposing their binaries to everyone else on the system? This lightning talk will show how to ship a real-world stack (kubelet, containerd, and runc) without making them accessible to the rest of the host. We will demonstrate how to use portable services and systemd capsules to allow these components to invoke each other and share some namespaces, all while keeping the host OS clean. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/K9GPKV/

Video:asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_hd.mp4

Recently systemd acquired functionality to download & invoke OCI containers directly. In this talk I'd like to explain where we are at with this, what we have, where the gaps are and where we are going, to make OCI containers a thing you can directly execute with systemd, without external tools. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BWWVCN/

Video:asg2026-435-eng-systemd_OCI_hd.mp4

The limitations of systemd-sysext/confext from the early days are mostly gone nowadays. The loading of extension images from the initrd means that generic content will behave as expected without any workarounds. New settings help making live reconfiguration work better as well. We will see how declarative configuration management with systemd-sysext/confext from git can be done with an OpenTofu/Terraform module. For image-based Linux binding configuration together with a pinned OS version is now possible through bootctl link. OS builders can ship /etc files through a default confext image. systemd-sysext/confext: https://www.freedesktop.org/software/systemd/man/devel/systemd-sysext.html bootctl: https://www.freedesktop.org/software/systemd/man/devel/bootctl.html Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/RMC879/

Video:asg2026-429-eng-An_update_on_systemd-sysext_confext_hd.mp4

Using mkosi and apparmor.d as building blocks, this talk presents a prototype minimal Debian server. The goal is not to provide yet another Linux distribution, but to explore how hard it is to build personalized, hardened server images. On top of the usual mkosi-backed features such as UKIs, A/B updates and dm-verity, the project adds a whole-system AppArmor policy and an immutable `/etc`. Because older devices also matter, the prototype supports the Raspberry Pi 3 (UEFI) too, with minor changes to the security model. The talk presents the differences in design, attacker model, and implementation between the various targets. This talk walks through a prototype: a minimal, hardened Debian server built with `mkosi` and `apparmor.d`. It composes three layers of systemd and Debian tooling that are well understood alone but rarely combined, each reinforcing the others: - **Image-based OS:** `mkosi` magic. - **Whole-system MAC:** AppArmor policies that confine every process on the system. It also brings: - Multi-layered policy loading, fixing the AppArmor load-time issues that hurt small devices. - Immutable security policies. - Compatibility with systemd sysext/confext. - **Immutable `/etc`:** assembled from signed `systemd-confext` images, closing immutability's usual escape hatch. The same image targets both an x86-64 server and a Raspberry Pi 3 (UEFI), and that contrast is where it gets interesting. The two share a single build but diverge on attacker model and security guarantees: what an embedded device with no Secure Boot can promise versus a server, and where the implementation has to bend. We walk those differences, the limitations, and what would have to land upstream to make this kind of image easier. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/KJNYQ8/

Video:asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_hd.mp4

Observability stacks have gotten good at CPU, memory, and network — but storage is still where the picture goes dark. When a workload stalls on I/O, device-level tools like iostat or blktrace tell you the disk was busy; they don't tell you which service caused it, or where in the stack the latency actually accrued: a slow fsync, writeback pressure in the page cache, a filesystem journal commit, or a saturated block queue. This talk follows a single write from the syscall boundary down to the block layer, using eBPF to instrument each handoff — VFS, the filesystem, the page cache, and block I/O submission and completion — without patching applications or running a custom kernel. We'll look at which attach points (tracepoints, fentry/fexit, kprobes) give honest per-layer latency, how to keep the measurement overhead from biasing the result, and how to attribute the latency back to the responsible cgroup or systemd service instead of an aggregate line on a dashboard. Examples range from fsync-heavy database commits to large sequential writes that look fine at the device level but stall well above it. Attendees will leave with a concrete method for turning storage from a black box into a traceable path — and an honest sense of where eBPF helps, and where it still can't see. Follow a single write from syscall to block layer with eBPF, measuring honest per-layer latency at each handoff and attributing storage stalls to the service that caused them. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/XHJX3N/

Video:asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_hd.mp4

Immutable, image-based Linux has gone mainstream — on Fedora. Nearly every atomic distro descends from the RPM/ostree lineage. Debian is conspicuously rare, with really only Vanilla OS and Endless OS to its name. There's a reason, and it's apt: Debian's package manager expects a writable root filesystem, so the moment you seal the rootfs, the native way to install and update software stops working. That's the wall every immutable Debian hits, and most climb it with Flatpak or containers. This talk takes a different route — Nix. Nix keeps everything in a self-contained, content-addressed /nix/store, so it never needs a writable rootfs. The base is built once with mkosi and frozen (apt isn't even installed) and Nix manages everything that changes after that, reproducibly. The result is an immutable Debian rootfs with the entire Nix package ecosystem available on top. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BEDGKF/

Video:asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_hd.mp4

IETF is standardizing a new ACME challenge, `device-attest-01`, which allows organizations to provision device bound certificates to machines, and enables machines to present signing certificates that can't be extracted out of machines they where intended for. This is useful for cases where you want to provide reverse proxies with mTLS with a strong sense of device identity. attezt is intended to be a suite of tools to work the new `device-attest-01` ACME challenges for Linux. It provides an ACME client, an attestation server with (simple) support for inventory systems and a PKCS11 agent which together enables the support of this ACME challenge on Linux. This talk will give an introduction to the new ACME challenge, a quick rundown of how an attestation server works and how attezt works. https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ https://github.com/Foxboron/attezt Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/8XRBTA/

Video:asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_hd.mp4

When you lock your systemd-homed enabled Linux desktop today, your home directory (including the desktop session) is fully frozen. This happens because systemd-homed uses a single cryptographic key (the LUKS volume key) and throws it away during lock. Want to lock away just your credentials as on a normal screen lock while keeping music playing and notifications coming through? You can't. This talk presents the work done as part of the systemd STF grant to extend the systemd-homed's key hierarchy that fixes this issue. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/TL3KGN/

Video:asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_hd.mp4

The storage directory settings in systemd help define where services store their data. Two important features have been implemented for these directories. The first one is id-mapped mounts, which is a filesystem feature that allows a mount namespace to show a different UID than what is stored on a file. Storage directories now support id-mapping, so that the files within the mount namespace of a service defined with DynamicUser=yes are owned by its unprivileged UID/GID. The second feature is storage quota support. Storage limits can now be defined in terms of percentages or absolute values to enforce quotas on the consumption of State, Cache, and Logs directories. These features enhance the security and resource management of systemd services. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/N93KWW/

Video:asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_hd.mp4

Marco will review the state of systemd sandboxing in Debian packages, what we need to fix to have more and what will break by enabling too much of it. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/VLBXZ8/

Video:asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_hd.mp4