<?xml version='1.0' encoding='utf-8' ?>
<!-- Made with love by pretalx v2024.2.0.dev0. -->
<schedule>
    <generator name="pretalx" version="2024.2.0.dev0" />
    <version>0.9</version>
    <conference>
        <title>All Systems Go! 2024</title>
        <acronym>all-systems-go-2024</acronym>
        <start>2024-09-25</start>
        <end>2024-09-26</end>
        <days>2</days>
        <timeslot_duration>00:05</timeslot_duration>
        <base_url>https://cfp.all-systems-go.io</base_url>
        <logo>https://cfp.all-systems-go.io/media/all-systems-go-2024/img/ASG_social-avatar_Nl7AMBw_a3l9zR4.png</logo>
        <time_zone_name>Europe/Berlin</time_zone_name>
        
        
    </conference>
    <day index='1' date='2024-09-25' start='2024-09-25T04:00:00+02:00' end='2024-09-26T03:59:00+02:00'>
        <room name='Main Hall' guid='cea80a4f-8388-55dc-84b6-1a45297cf2cd'>
            <event guid='7e768d80-1df4-529f-a191-bf316872df90' id='318'>
                <room>Main Hall</room>
                <title>Opening session of All Systems Go! 2024</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T09:25:00+02:00</date>
                <start>09:25</start>
                <duration>00:05</duration>
                <abstract>A welcome session for All Systems Go!</abstract>
                <slug>all-systems-go-2024-318-opening-session-of-all-systems-go-2024</slug>
                <track></track>
                
                <persons>
                    
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFTCGE/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFTCGE/feedback/</feedback_url>
            </event>
            <event guid='f3305f05-435b-522f-bf16-fe268c411ea5' id='251'>
                <room>Main Hall</room>
                <title>Reproducible and Immutable OS Images with NixOS</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>00:40</duration>
                <abstract>Many consider NixOS a great tool for declarative definition of their OS, but only few know about its capabilities for Image-based Linux. NixOS offers the tools to combine modern technologies such as discoverable disk images (DDIs), unified kernel images (UKIs), and TPM-based measured boot for transforming declarative configurations into security-focused and immutable OS images for both the server and the desktop.

This talk showcases how we build such reproducible and immutable DDIs with NixOS, and how ukify, systemd-repart, dm-verity and measured boot are involved in that process. We will also briefly cover the support of SecureBoot in NixOS through the Lanzaboote project, and what else is yet to come for image-based NixOS.</abstract>
                <slug>all-systems-go-2024-251-reproducible-and-immutable-os-images-with-nixos</slug>
                <track></track>
                
                <persons>
                    <person id='199'>Moritz Sanft</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/MRDURE/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/MRDURE/feedback/</feedback_url>
            </event>
            <event guid='f30e92f5-9f8c-5a96-9dc1-4616bd6af96d' id='292'>
                <room>Main Hall</room>
                <title>Using Trusted Platform Modules (TPMs) at scale for protecting keys</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T10:15:00+02:00</date>
                <start>10:15</start>
                <duration>00:25</duration>
                <abstract>Meta runs a large production fleet of servers, all making extensive use of TLS for inter-host communication. As part of a general approach of securing keys against exfiltration a project has been undertaken to make use of existing TPM chips to provide secure storage for high privilege private keys. This talk will touch upon the approach taken to allow for the use of a hardware backed key without compromising performance, but mostly focus on the software infrastructure that needed to be built to provision and monitor TPM health across the fleet (a prerequisite for confirmation of viability).</abstract>
                <slug>all-systems-go-2024-292-using-trusted-platform-modules-tpms-at-scale-for-protecting-keys</slug>
                <track></track>
                
                <persons>
                    <person id='227'>Jonathan McDowell</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/JQZ78P/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/JQZ78P/feedback/</feedback_url>
            </event>
            <event guid='be3241e8-53ad-5596-b429-33c887d9f149' id='265'>
                <room>Main Hall</room>
                <title>Enhancing Security with Systemd: Secure Web Tokens and TPM 2.0</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T10:45:00+02:00</date>
                <start>10:45</start>
                <duration>00:25</duration>
                <abstract>As the digital landscape evolves, ensuring robust security measures becomes paramount. In this talk, we will explore the implementation of a new systemd service designed to enhance secure web token management through TPM 2.0 and FIDO2 support. This integration facilitates seamless interaction with the xdg-credentials-portal, aiming to provide a straightforward and secure approach to handling credentials.</abstract>
                <slug>all-systems-go-2024-265-enhancing-security-with-systemd-secure-web-tokens-and-tpm-2-0</slug>
                <track></track>
                
                <persons>
                    <person id='209'>Philipp Deppenwiese</person>
                </persons>
                <language>en</language>
                <description>Key Points:

Systemd Service Implementation: An in-depth look at how we are leveraging systemd to create a secure service for web tokens.
TPM 2.0 and FIDO2 Integration: Understanding the role of TPM 2.0 and FIDO2 in enhancing hardware security.
Seamless Integration with xdg-credentials-portal: Demonstrating the ease of use and benefits of integrating with the xdg-credentials-portal for secure credential management.
New Functionality in Systemd: Discussing the significance of this new functionality and its potential impact on the systemd community.
Targeted at systemd developers and enthusiasts, this session will provide valuable insights into the implementation process, the benefits of using TPM 2.0 modules for hardware security, and the overall enhancement of systemd functionalities. Attendees will leave with a clear understanding of the concepts and the practical steps required to integrate these security features into their own projects.

Join us to explore the future of secure web tokens with systemd and how this integration can simplify and strengthen security protocols in your system architecture.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9KSPSA/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9KSPSA/feedback/</feedback_url>
            </event>
            <event guid='bce86c58-94c5-5e07-885b-7bd20ac3db30' id='259'>
                <room>Main Hall</room>
                <title>Full Disk Encryption in openSUSE MicroOS and Tumbleweed</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T11:15:00+02:00</date>
                <start>11:15</start>
                <duration>00:40</duration>
                <abstract>The openSUSE project has been looking for a Full Disk Encryption (FDE) solution since long ago. After some iterations we are converging in a systemd based solution. This talks will present the alternatives and will focus in the current proposed solution based on systemd-pcrlock.</abstract>
                <slug>all-systems-go-2024-259-full-disk-encryption-in-opensuse-microos-and-tumbleweed</slug>
                <track></track>
                
                <persons>
                    <person id='81'>Alberto Planas Dominguez</person>
                </persons>
                <language>en</language>
                <description>The openSUSE distribution is moving toward a FDE based on systemd, using signed policies or nvindex policies.  We will review the different solutions that we worked on, and we will compare them briefly. We also describe some of the architectural changes done in the distribution before we can use the systemd tools.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/93KLUJ/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/93KLUJ/feedback/</feedback_url>
            </event>
            <event guid='1c377bca-6794-5d78-aaf1-553fd2d42538' id='309'>
                <room>Main Hall</room>
                <title>The road to a trusted and measured boot chain in Bootable Containers</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T11:55:00+02:00</date>
                <start>11:55</start>
                <duration>00:40</duration>
                <abstract>Fedora image based variants (CoreOS, Atomic Desktops, IoT) are currently built using ostree and rpm-ostree. This enables an hybrid approach where the system is managed like an image but modifications are still possible using RPMs.

But this approach has limits:
- It is difficult for users to customize their operating system and share those customizations.
- The integrity of the boot chain is not guarenteed and it is costly to validate the system content at runtime.

To address those shortcomings, we are introducing the bootable containers (bootc) project. With bootable containers, the content of the operating system, including the kernel and initrd (or a UKI) is shipped in a container image alongside its corresponding base userspace root filesystem. This image can then be modified using container native tools and shared via a container registry.

To chain from platform Secure Boot to a verified root filesystem, the ostree project has integrated support for composefs. It combines multiple Linux kernel features (overlayfs, EROFS and fs-verity) to provide read-only mountable filesystem trees stacking on top of an underlying &quot;lower&quot; Linux filesystem.

We will detail how we are integrating composefs and UKI support in Bootable Containers to enable a trusted and measured boot chain while letting users customize and re-sign their images to fit their needs.</abstract>
                <slug>all-systems-go-2024-309-the-road-to-a-trusted-and-measured-boot-chain-in-bootable-containers</slug>
                <track></track>
                
                <persons>
                    <person id='244'>Timoth&#233;e Ravier</person><person id='258'>JB Trystram</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/HVEZQQ/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/HVEZQQ/feedback/</feedback_url>
            </event>
            <event guid='7ea1f603-1d9d-5335-9352-f434c9be69b3' id='264'>
                <room>Main Hall</room>
                <title>systemd 255 in Tizen, or how we have paid our technical debt and took another one</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T12:40:00+02:00</date>
                <start>12:40</start>
                <duration>00:25</duration>
                <abstract>In this talk we present the story of upgrading systemd in Tizen by eleven releases. We share both the lessons we&apos;ve learnt during the most recent upgrade as well as decade long experience of the maintenance and development of key packages in the only GNU/Linux distribution that uses kdbus. We describe our day-to-day git workflow as well as upgrade procedures we came up with over the years.</abstract>
                <slug>all-systems-go-2024-264-systemd-255-in-tizen-or-how-we-have-paid-our-technical-debt-and-took-another-one</slug>
                <track></track>
                
                <persons>
                    <person id='208'>&#321;ukasz Stelmach</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/QLJGJJ/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/QLJGJJ/feedback/</feedback_url>
            </event>
            <event guid='39db42ce-958c-56cd-b9a6-3ef6a3c03fbc' id='308'>
                <room>Main Hall</room>
                <title>Platform security in NixOS</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T14:35:00+02:00</date>
                <start>14:35</start>
                <duration>00:40</duration>
                <abstract>You may have heard about this weird distribution, NixOS, that breaks compatibility with /usr. 
This talk explores the properties inherent to NixOS, focusing on its distinct approach to package management and system configuration. Learn how these principles combine with general upstream efforts at bringing TPM2, Secure Boot and more to your Linux distribution.</abstract>
                <slug>all-systems-go-2024-308-platform-security-in-nixos</slug>
                <track></track>
                
                <persons>
                    <person id='243'>Ryan Lahfa</person><person id='255'>Niklas Sturm</person>
                </persons>
                <language>en</language>
                <description>Everything you wanted to know about why NixOS do things a certain way will be answered here. The idea is that you get out of this talk understanding the different compromises done by the NixOS community and what they get out of it.

We will cover https://github.com/nix-community/lanzaboote which is a Rust UEFI stub similar to systemd-stub with fewer features but with one unique special feature for NixOS, similar to UKI addons.

We will also do a status report of where NixOS stands in terms of adoption of systemd features such as systemd-pcrlock.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/UQ3CYU/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/UQ3CYU/feedback/</feedback_url>
            </event>
            <event guid='7f1f20b6-2d00-5d2e-8e18-be390d7da2d3' id='275'>
                <room>Main Hall</room>
                <title>systemd &amp; TPM in 2024</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T15:20:00+02:00</date>
                <start>15:20</start>
                <duration>00:40</duration>
                <abstract>An update on systemd&apos;s TPM features, i.e. what happened since last year, i.e. systemd-pcrlock, NvPCRs, and Varlink APIs.</abstract>
                <slug>all-systems-go-2024-275-systemd-tpm-in-2024</slug>
                <track></track>
                
                <persons>
                    <person id='78'>Lennart Poettering</person>
                </persons>
                <language>en</language>
                <description>At last year&apos;s ASG I already did a systemd &amp; TPM talk, and this is supposed to be a follow-up to that, with everything that happened since then, plus what&apos;s next and what&apos;s missing.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/VQLZBT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/VQLZBT/feedback/</feedback_url>
            </event>
            <event guid='ece9fd92-34a6-5391-b0f3-61ebdedc0e64' id='315'>
                <room>Main Hall</room>
                <title>Portable software bills of materials with Nix and systemd portable services</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T16:30:00+02:00</date>
                <start>16:30</start>
                <duration>00:25</duration>
                <abstract>While software bills of materials become of increasing value to further trust in the software supply chain, generating high quality SBOMs still poses some challenges in some ecosystems due to the lack of proper tooling or accessible build metadata. In this talk, I&apos;ll explain and demonstrate how we can leverage the static dependency graph of functional package managers like Nix to generate very precise SBOMs, that can be relevant for running a service on any linux distribution thanks to systemd portable services.</abstract>
                <slug>all-systems-go-2024-315-portable-software-bills-of-materials-with-nix-and-systemd-portable-services</slug>
                <track></track>
                
                <persons>
                    <person id='250'>Julien Malka</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/7XGYDC/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/7XGYDC/feedback/</feedback_url>
            </event>
            <event guid='9d9014b2-476e-5c32-a53c-f4491c179555' id='313'>
                <room>Main Hall</room>
                <title>Waiter, an OS please, with some sysext sprinkled on top</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T17:00:00+02:00</date>
                <start>17:00</start>
                <duration>00:25</duration>
                <abstract>On general purpose image based systems such as Flatcar and Fedora CoreOS, users are encouraged to run all their applications using containers. To make updates safe and predictable, the system is mounted as read only and local modifications are discouraged.

While containers offer a lot of flexibility on Linux, there are still cases where installing binaries or running applications directly on the host operating system is preferred. For example to add kernel modules, use an alternative container runtime version, add more udev rules, etc.

Some of those use cases could be addressed with statically linked binaries, but their management is manual and their usage creates new issues around updates, versionning, memory footprint and not everything can be statically compiled. Alternatively, one can build its own image but at non-negligeable maintenance costs.

Systemd&apos;s system extensions (sys-ext) provide a mechanism to extend the content of the host while preserving the safety guarentees around updates. We will demonstrate how Flatcar, Fedora CoreOS and Atomic Desktops are leveraging sysext images to securely extend the OS. With practical examples and usecases (e.g Cluster API) learn how to install Python, Podman, Kubernetes, ZFS, everything at the same time, by composing your very own image with systemd-sysext.</abstract>
                <slug>all-systems-go-2024-313-waiter-an-os-please-with-some-sysext-sprinkled-on-top</slug>
                <track></track>
                
                <persons>
                    <person id='248'>Mathieu Tortuyaux</person><person id='244'>Timoth&#233;e Ravier</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/HJLF3C/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/HJLF3C/feedback/</feedback_url>
            </event>
            <event guid='a5f25d89-3346-54b5-a0bb-0496241657da' id='271'>
                <room>Main Hall</room>
                <title>Rediscovering systemd Portable Services</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T17:30:00+02:00</date>
                <start>17:30</start>
                <duration>00:25</duration>
                <abstract>systemd introduced Portable Services support in 2018, as part of v239. This feature was covered at ASG 2018 and in a blog post published at the time: https://0pointer.net/blog/walkthrough-for-portable-services.html
But a lot has changed in the past 6 years, and very crucial new features have been introduced, so it is time to have another look at this topic and see what has happened in the meanwhile, what new use cases have opened up, and what is coming in the near future.

https://systemd.io/PORTABLE_SERVICES/</abstract>
                <slug>all-systems-go-2024-271-rediscovering-systemd-portable-services</slug>
                <track></track>
                
                <persons>
                    <person id='128'>Luca Boccassi</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/DGVBSC/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/DGVBSC/feedback/</feedback_url>
            </event>
            <event guid='c4be1b16-c25d-5760-8f03-bc488ce99709' id='311'>
                <room>Main Hall</room>
                <title>Efficient RAUC Updates using composefs</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T18:00:00+02:00</date>
                <start>18:00</start>
                <duration>00:05</duration>
                <abstract>A quick overview of how RAUC uses libcomposefs to handle new use-cases.</abstract>
                <slug>all-systems-go-2024-311-efficient-rauc-updates-using-composefs</slug>
                <track></track>
                
                <persons>
                    <person id='246'>Jan L&#252;bbe</person>
                </persons>
                <language>en</language>
                <description>Traditionally, RAUC focused on A/B updates for whole partitions, either by
using filesystem images or tar archives. While the image-based OS approach
has many benefits, there are scenarios where more loosely coupled components
need to be handle in addition to the root filesystem.
In RAUC, these can be handled with using the new &quot;artifact updates&quot; support.

As a system might have many artifacts installed in parallel, such as for
containers (systemd-nspawn or otherwise) and systemd-sysexts, efficient storage
is important. In many cases, these are updated often, so download efficiency is
important as well.

After evaluating multiple alternatives, we&apos;ve now decided to integrate composefs.
Besides solving the requirements above, it additionally provides the same level
of integrity protection as a dm-verity root filesystem, which is important in
systems using secure boot.

This talk will show how RAUC uses libcomposefs and the new use-cases supported
by having an efficient content-addressed backing store with full authentication.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/3DKX9V/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/3DKX9V/feedback/</feedback_url>
            </event>
            <event guid='1bd5ae35-703c-5d99-9830-25a98132ff61' id='314'>
                <room>Main Hall</room>
                <title>oo7-daemon + systemd per-user credentials</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T18:05:00+02:00</date>
                <start>18:05</start>
                <duration>00:05</duration>
                <abstract>oo7-daemon (a temporary name based on the oo7 client library) project aims to provide a replacement for the gnome-keyring-daemon as the new D-Bus Secret Service provider in the GNOME desktop environment. In this talk I will go through the latest development plans and the progress made to integrate TPM backed credentials support to oo7-daemon using systemd per-user credentials as a backend.</abstract>
                <slug>all-systems-go-2024-314-oo7-daemon-systemd-per-user-credentials</slug>
                <track></track>
                
                <persons>
                    <person id='249'>Dhanuka Warusadura</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/8TMT9T/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/8TMT9T/feedback/</feedback_url>
            </event>
            <event guid='5cf95c8e-1ddd-5e31-8d06-cd8bab26207b' id='284'>
                <room>Main Hall</room>
                <title>Debian, empty /var/, empty /etc/ and factory reset</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T18:10:00+02:00</date>
                <start>18:10</start>
                <duration>00:05</duration>
                <abstract>This presentation will review how far Debian (and more generally, traditional distributions) is from supporting factory reset: what can work, what is missing and possible hacks^Wways to do it without starting a distribution-wide effort.</abstract>
                <slug>all-systems-go-2024-284-debian-empty-var-empty-etc-and-factory-reset</slug>
                <track></track>
                
                <persons>
                    <person id='224'>Marco d&apos;Itri</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/3K8NZT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/3K8NZT/feedback/</feedback_url>
            </event>
            <event guid='b867a151-17c0-5663-90e2-f89ee2aa03a4' id='321'>
                <room>Main Hall</room>
                <title>Integration testing environment for mixed HPC and cloud workloads</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T18:15:00+02:00</date>
                <start>18:15</start>
                <duration>00:05</duration>
                <abstract>Integration testing environment for mixed HPC and cloud workloads</abstract>
                <slug>all-systems-go-2024-321-integration-testing-environment-for-mixed-hpc-and-cloud-workloads</slug>
                <track></track>
                
                <persons>
                    
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/XNQLTE/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/XNQLTE/feedback/</feedback_url>
            </event>
            <event guid='8706410f-a327-50c3-a0e8-d7d96575c27e' id='322'>
                <room>Main Hall</room>
                <title>A new way to develop on immutable Linux</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T18:20:00+02:00</date>
                <start>18:20</start>
                <duration>00:05</duration>
                <abstract>A new way to develop on immutable Linux</abstract>
                <slug>all-systems-go-2024-322-a-new-way-to-develop-on-immutable-linux</slug>
                <track></track>
                
                <persons>
                    
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/NSKLAR/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/NSKLAR/feedback/</feedback_url>
            </event>
            <event guid='f9451f76-265a-5da9-bd81-f6cd2a07a0cf' id='323'>
                <room>Main Hall</room>
                <title>Ideas for improving systemd-boot</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-25T18:25:00+02:00</date>
                <start>18:25</start>
                <duration>00:05</duration>
                <abstract>Ideas for improving systemd-boot</abstract>
                <slug>all-systems-go-2024-323-ideas-for-improving-systemd-boot</slug>
                <track></track>
                
                <persons>
                    
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/DT3RCU/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/DT3RCU/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Dome' guid='7fc98a2b-9ada-5cda-ab77-97c74395cf6b'>
            <event guid='54ae33b3-41ef-5d5e-a54e-0ae9f7330cc9' id='290'>
                <room>Dome</room>
                <title>Introducing azure-init, a minimal provisioning agent written in Rust</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T10:15:00+02:00</date>
                <start>10:15</start>
                <duration>00:25</duration>
                <abstract>[Azure-init](https://github.com/Azure/azure-init) is a fresh open source reference implementation for provisioning Linux virtual machines in Azure. In contrast to existing systems like cloud-init, azure-init aims to be minimal, focusing on basic instance initialization from Azure metadata. Azure-init also consists of a flexible structure to enable its use by other provisioning agents like Fedora CoreOS&#8217; [Afterburn](https://github.com/coreos/afterburn/). Finally, azure-init aims to be fast and secure, being written in Rust. In this talk we will review the motivations for the creation of azure-init, the current status of the project, and vision for its future development.</abstract>
                <slug>all-systems-go-2024-290-introducing-azure-init-a-minimal-provisioning-agent-written-in-rust</slug>
                <track></track>
                
                <persons>
                    <person id='35'>Dongsu Park</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/BK7KMD/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/BK7KMD/feedback/</feedback_url>
            </event>
            <event guid='9f83056d-1f96-5d1e-8e7c-e6c552246e76' id='280'>
                <room>Dome</room>
                <title>Improving bpftrace reliability</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T10:45:00+02:00</date>
                <start>10:45</start>
                <duration>00:25</duration>
                <abstract>bpftrace is a popular and powerful dynamic tracer for Linux systems. In the vast majority of uses cases, bpftrace does its job quickly, efficiently, and accurately. However with the rapid increase of users, use cases, and features, the bpftrace community has started to feel (technical) growing pains. In particular, we&apos;ve started to uncover various reliability issues. In this talk, we will cover what is already done as well as what is currently broken and how we will systematically fix and prevent these issues from re-occuring.</abstract>
                <slug>all-systems-go-2024-280-improving-bpftrace-reliability</slug>
                <track></track>
                
                <persons>
                    <person id='51'>Daniel Xu</person>
                </persons>
                <language>en</language>
                <description>Because bpftrace sits at the intersection of operating systems, compilers, and observability, we have the fortunate advantage of being able to absorb techniques and tricks from these fairly different disciplines. We hope that some of the knowledge we share will be both interesting as well practical to attendees.

Audience participation is highly welcome. In particular, we are quite interested in receiving feedback in the form of bug reports, feature requests, complaints, etc.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/MXAEYZ/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/MXAEYZ/feedback/</feedback_url>
            </event>
            <event guid='a12dc80f-bbf8-5228-bd73-9afbfcaefea4' id='287'>
                <room>Dome</room>
                <title>eBPF Data Collection for Everyone &#8211; empowering the community to obtain Linux insights using Inspektor Gadget</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T11:15:00+02:00</date>
                <start>11:15</start>
                <duration>00:40</duration>
                <abstract>In this presentation we show how eBPF programmers can easily distribute their programs using Inspektor Gadget, a tool designed for the creation, deployment, and execution of eBPF programs (gadgets) across Kubernetes and Linux environments. Inspektor Gadget encapsulates eBPF programs into OCI containers, providing well-understood and easily distributable units.  We then detail how an end user can use Inspektor Gadget to easily derive valuable systems insights.</abstract>
                <slug>all-systems-go-2024-287-ebpf-data-collection-for-everyone-empowering-the-community-to-obtain-linux-insights-using-inspektor-gadget</slug>
                <track></track>
                
                <persons>
                    <person id='28'>Alban Crequy</person><person id='231'>Michael Friese</person>
                </persons>
                <language>en</language>
                <description>We&apos;ll give a brief overview of Inspektor Gadget&apos;s automatic data enrichment process, transforming complex kernel information into high-level, understandable concepts tied to Kubernetes and container runtimes. This feature bridges the knowledge gap between raw, low-level data and more interpretable information, improving the understanding of system behavior.
We will explain how users can write their own gadgets and make use of different helper APIs provided by Inspektor Gadget for socket enricher, file path discovery and container filtering, etc.
We will show how to combine existing gadgets into a new one, add additional post-processing logic  using WASM or Lua and export the resulting data to different targets, using for example OpenTelemetry.
Throughout the talk, we&apos;ll demonstrate more of Inspektor Gadget&apos;s features, its support across various environments, discuss its operational mechanics, and share insights into the future direction of the project.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/PVGU77/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/PVGU77/feedback/</feedback_url>
            </event>
            <event guid='2dc340b4-8277-5885-9100-54e3b6f48a59' id='286'>
                <room>Dome</room>
                <title>Fixing an old Linux process memory security bug</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T11:55:00+02:00</date>
                <start>11:55</start>
                <duration>00:40</duration>
                <abstract>There is a well-known trade-off between security lockdowns and a user&apos;s abiliy to
debug/inspect a system. The Linux kernel is finally fixing an old proc/mem security
bug which illustrates this trade-off nicely. The kernel will provide a mechanism,
so distros need to implement a policy according to their own security needs, to
restrict proc/mem access (it gives userspace RW access to processes memory).

This talk goes into the what, why and how of getting this bug fixed, with some policies
for plugging the long-standing hole for different use-cases, without breaking
debuggers or container supervisors.</abstract>
                <slug>all-systems-go-2024-286-fixing-an-old-linux-process-memory-security-bug</slug>
                <track></track>
                
                <persons>
                    <person id='213'>Adrian Ratiu</person>
                </persons>
                <language>en</language>
                <description>This talk is based the Linux patch series [1] which is extending the /proc/*/mem access
controls beyond the normal file-based permissions, to restrict various access during
kernel builds (Kconfig level) or early boot via static/read-only key parameters. It
is expected to land in kernel v6.11, to be released in late Q3 / early Q4 2024.
The author is looking for opinions whether this should be backported to stable trees
since the patch is somewhere between a bugfix and a new feature.

[1] https://patchwork.kernel.org/project/linux-fsdevel/patch/20240613133937.2352724-2-adrian.ratiu@collabora.com/</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9UVMR7/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9UVMR7/feedback/</feedback_url>
            </event>
            <event guid='1923b927-629b-5dfd-9383-fb139f7a0842' id='279'>
                <room>Dome</room>
                <title>Lessons learned from migrating AI accelerator drivers from the kernel to userspace</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T12:40:00+02:00</date>
                <start>12:40</start>
                <duration>00:25</duration>
                <abstract>The kernel driver is dead; long live the userspace driver! In this talk, we&#8217;ll discuss the motivation, challenges and outcomes of migrating drivers for Meta&#8217;s AI accelerator chips from the kernel to userspace.</abstract>
                <slug>all-systems-go-2024-279-lessons-learned-from-migrating-ai-accelerator-drivers-from-the-kernel-to-userspace</slug>
                <track></track>
                
                <persons>
                    <person id='222'>George Utsin</person>
                </persons>
                <language>en</language>
                <description>Topics include:
- Managing systemd units at scale
- Experiences of running IPC over D-Bus
- Re-writing the driver in Rust
- The tooling necessary to support a variety of environments
- Overall deprecation challenges and wins</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/77PFFF/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/77PFFF/feedback/</feedback_url>
            </event>
            <event guid='114574b7-c1a3-51ad-8834-9440df675e51' id='249'>
                <room>Dome</room>
                <title>Fort Kairos: A New Dawn for Secure Linux in Untrusted Environments</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T14:35:00+02:00</date>
                <start>14:35</start>
                <duration>00:40</duration>
                <abstract>At the edge, there&apos;s one thing we know for sure: it&apos;s not to be trusted. But imagine if Kairos could change that, letting you sleep soundly knowing your intellectual property is secure.

Kairos is a fully open source project to run kubernetes at the edge. As such, we have put Trusted Boot into action. Inspired by Lennard Pottering, the mind behind Systemd, we&apos;ve leveraged Secure Boot, Trusted Boot, TPM, and disk encryption. The result? A Linux OS that&apos;s built tough against the challenges of untrusted environments.</abstract>
                <slug>all-systems-go-2024-249-fort-kairos-a-new-dawn-for-secure-linux-in-untrusted-environments</slug>
                <track></track>
                
                <persons>
                    <person id='198'>Mauro Morales</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9VPPTC/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9VPPTC/feedback/</feedback_url>
            </event>
            <event guid='c53164c4-5788-5c80-8f43-d61333faf80d' id='266'>
                <room>Dome</room>
                <title>bootc: Generating an ecosystem around bootable OCI containers</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T15:20:00+02:00</date>
                <start>15:20</start>
                <duration>00:40</duration>
                <abstract>Containers have become the de facto choice for deploying most applications, and all of us benefit from the isolation, portability, and the surrounding ecosystem.   In this talk we&#8217;ll take a deep dive into the world of bootable containers, using the same ideas, goals and technology for the host system (whether virtualized or bare metal).  We&#8217;ll look at the bootc project under the github.com/containers umbrella and its current flagship distribution usage in the new Fedora/CentOS bootc project and initiative.  We hope you are as excited as we are by taking cloud-native approaches down to the operating system level, and a key goal is finding points that can be shared with other components of the ecosystem, from the uapi-group.org to other container-based OSes.</abstract>
                <slug>all-systems-go-2024-266-bootc-generating-an-ecosystem-around-bootable-oci-containers</slug>
                <track></track>
                
                <persons>
                    <person id='43'>Ben Breard</person><person id='211'>Colin Walters</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/LA9LXV/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/LA9LXV/feedback/</feedback_url>
            </event>
            <event guid='ec605407-e1c6-56d7-8ac0-7a343e0221fa' id='303'>
                <room>Dome</room>
                <title>An extendable and securely signed image-based OS with updates</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T16:30:00+02:00</date>
                <start>16:30</start>
                <duration>00:25</duration>
                <abstract>With systemd tooling, including mkosi, it is possible to build an OS image that fulfills all checkmarks a modern image-based OS should have, but with a standard off-the-shelf distribution!
This talk gives an overview for a possible workflow, including A/B updates and offline signed images and updates, in real-use. As a bonus, it is also self-replicating and uses as little configuration as possible, leveraging built-in systemd auto detection.</abstract>
                <slug>all-systems-go-2024-303-an-extendable-and-securely-signed-image-based-os-with-updates</slug>
                <track></track>
                
                <persons>
                    <person id='236'>Marius Schiffer</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/LJAYYL/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/LJAYYL/feedback/</feedback_url>
            </event>
            <event guid='d7383c4a-91c8-5292-b611-02ad259b2c33' id='312'>
                <room>Dome</room>
                <title>Creating Arch Linux images using mkosi</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T17:00:00+02:00</date>
                <start>17:00</start>
                <duration>00:25</duration>
                <abstract>Arch Linux creates 2 cloud images, 2 vagrant images every month using custom bash scripts and requiring root for building. This talk will look at how these images can be created using mkosi, building them in CI, testing the build images and as a bonus; build reproducible?

Project link: https://gitlab.archlinux.org/archlinux/arch-boxes</abstract>
                <slug>all-systems-go-2024-312-creating-arch-linux-images-using-mkosi</slug>
                <track></track>
                
                <persons>
                    <person id='247'>Jelle van der Waa</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/QFUGLT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/QFUGLT/feedback/</feedback_url>
            </event>
            <event guid='8086a40b-8550-5052-805b-8a903fa5dc0b' id='260'>
                <room>Dome</room>
                <title>interacting with systemd from high level languages</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-25T17:30:00+02:00</date>
                <start>17:30</start>
                <duration>00:25</duration>
                <abstract>Probably the way systemd is thought of and used is mostly as a service manager, and a collection of tools built around the idea of &#8220;low level user space&#8221;. We rarely think of it as a library that can be used as part of any high level language or application. This talk will cover this aspect of systemd, and through the lens of pystemd, explore how applications can use (and abuse) systemd.</abstract>
                <slug>all-systems-go-2024-260-interacting-with-systemd-from-high-level-languages</slug>
                <track></track>
                
                <persons>
                    <person id='170'>Alvaro Leiva Geisse</person>
                </persons>
                <language>en</language>
                <description>Probably the way systemd is thought of and used is mostly as a service manager, and a collection of tools built around the idea of &#8220;low level user space&#8221;. We rarely think of it as a library that can be used as part of any high level language or application. This talk will cover this aspect of systemd, and through the lens of pystemd, explore how applications can use (and abuse) systemd.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/VAQPQW/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/VAQPQW/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    <day index='2' date='2024-09-26' start='2024-09-26T04:00:00+02:00' end='2024-09-27T03:59:00+02:00'>
        <room name='Main Hall' guid='cea80a4f-8388-55dc-84b6-1a45297cf2cd'>
            <event guid='789104b6-c47a-51be-91ff-0b62d29429f0' id='269'>
                <room>Main Hall</room>
                <title>systemd: state of the project</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>00:25</duration>
                <abstract>Same as every year, a lot has happened in the systemd project since last year&apos;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.</abstract>
                <slug>all-systems-go-2024-269-systemd-state-of-the-project</slug>
                <track></track>
                
                <persons>
                    <person id='128'>Luca Boccassi</person><person id='137'>Zbigniew J&#281;drzejewski-Szmek</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/RLZEPD/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/RLZEPD/feedback/</feedback_url>
            </event>
            <event guid='41d61f94-49ff-5742-9837-7f809b0fb260' id='299'>
                <room>Main Hall</room>
                <title>systemd: round table</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T09:55:00+02:00</date>
                <start>09:55</start>
                <duration>00:25</duration>
                <abstract>Let&apos;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.</abstract>
                <slug>all-systems-go-2024-299-systemd-round-table</slug>
                <track></track>
                <logo>/media/all-systems-go-2024/submissions/YQZBGT/f17boot_Njd2Ilw.png</logo>
                <persons>
                    <person id='137'>Zbigniew J&#281;drzejewski-Szmek</person><person id='128'>Luca Boccassi</person><person id='78'>Lennart Poettering</person><person id='241'>Mike Yuan</person><person id='242'>Yu Watanabe</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/YQZBGT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/YQZBGT/feedback/</feedback_url>
            </event>
            <event guid='6a96d685-b834-5be1-bc0b-60da2c3c29e6' id='276'>
                <room>Main Hall</room>
                <title>Varlink Now!</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T10:20:00+02:00</date>
                <start>10:20</start>
                <duration>00:25</duration>
                <abstract>Why bother with Varlink IPC, and why now?</abstract>
                <slug>all-systems-go-2024-276-varlink-now-</slug>
                <track></track>
                
                <persons>
                    <person id='78'>Lennart Poettering</person>
                </persons>
                <language>en</language>
                <description>The Varlink IPC has been around for a while, but recently we started using it heavily in systemd. In this talk I&apos;d like to explain what Varlink IPC is, and why we are now adopting it so heavily. And I also want to explain why I think that Varlink is a good candidate as IPC of choice for any Linux software, both low-level and higher-level. We&apos;ll compare it with D-Bus in particular, and highlight where it shines (and where it doesn&apos;t shine so much).</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/XSYMKW/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/XSYMKW/feedback/</feedback_url>
            </event>
            <event guid='0f08f9a2-a963-52cd-9ea7-ea81259e0d3e' id='278'>
                <room>Main Hall</room>
                <title>systemd-ifying postmarketOS, our immutable future, and why Alpine is cooler than you thought</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T10:50:00+02:00</date>
                <start>10:50</start>
                <duration>00:40</duration>
                <abstract>postmarketOS was started with the lofty goal of enabling long term support for
mobile phones and other devices with traditionally short lifespans, and doing so
outside of the Android walled garden. This has inevitably resulted in a lot of
upstream focused hardware bringup and development. Join us and learn what
our community have been building, how we&apos;re running systemd on Alpine Linux
and what we see in the future for postmarketOS.</abstract>
                <slug>all-systems-go-2024-278-systemd-ifying-postmarketos-our-immutable-future-and-why-alpine-is-cooler-than-you-thought</slug>
                <track></track>
                
                <persons>
                    <person id='220'>Caleb Connolly</person><person id='221'>Clayton Craft</person>
                </persons>
                <language>en</language>
                <description>Through community driven efforts and collaboration, postmarketOS has grown into
a highly adaptable platform which runs on anything from smartwatches and TVs to
phones and laptops.

In this talk, Caleb and Clayton discuss how our unique approach to tooling and
package management have allowed such a small community to scale up to support
hundreds of devices with more than 5 different bootloaders, over a dozen user
interfaces, and now two init systems.

They will cover:

* A rough overview of the distro architecture
* How device abstractions work in postmarketOS 
* Pmbootstrap and apk for fast developer iteration at a low cost
* Systemd bootstrapping and current status
* Our plan for an immutable postmarketOS (and request for feedback)</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/LJXCKK/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/LJXCKK/feedback/</feedback_url>
            </event>
            <event guid='2f7cb6c1-60a9-507e-b099-371e6c45cf80' id='258'>
                <room>Main Hall</room>
                <title>Integrating systemd soft-reboot into a distribution and surviving it</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T11:35:00+02:00</date>
                <start>11:35</start>
                <duration>00:40</duration>
                <abstract>In this talk, I will discuss how Linux distributions can integrate and benefit from using systemd soft-reboot. Using openSUSE Tumbleweed as an example, I will show where and how it makes sense for traditional Linux distributions to use it and where the pitfalls are. With openSUSE MicroOS, we have a distribution with a read-only root file system that particularly benefits from a soft-reboot because a reboot is necessary after every update in order to change the root file system. However, this also requires special measures to ensure that it always functions smoothly.

Afterwards I will talk about the requirements and solutions for services to survive a soft reboot and what&apos;s necessary to make the whole thing supportable.</abstract>
                <slug>all-systems-go-2024-258-integrating-systemd-soft-reboot-into-a-distribution-and-surviving-it</slug>
                <track></track>
                
                <persons>
                    <person id='82'>Thorsten Kukuk</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/YUAPMX/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/YUAPMX/feedback/</feedback_url>
            </event>
            <event guid='ff1ca6fa-d11f-5418-b15f-f257510881fe' id='261'>
                <room>Main Hall</room>
                <title>What&apos;s your PID 1 up to?</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T12:20:00+02:00</date>
                <start>12:20</start>
                <duration>00:40</duration>
                <abstract>How do you continually test and release new versions of systemd with confidence? Also, once released, how do you monitor PID 1 itself and your PID 1 usage across your server fleet? This talk dives into Meta&#8217;s way of answering these questions so we can minimize the risk of breaking changes and fun each systemd release brings us. Some of the technology in the talk is OSS, so you too, can join in on the fun knowing how your systemd usage is across your own infrastructure!</abstract>
                <slug>all-systems-go-2024-261-what-s-your-pid-1-up-to-</slug>
                <track></track>
                <logo>/media/all-systems-go-2024/submissions/7APG3H/cooper_professional_dAM0PB3.jpeg</logo>
                <persons>
                    <person id='206'>Cooper Ry Lees</person>
                </persons>
                <language>en</language>
                <description>This talk will dive into how Meta baseline&#8217;s our systemd usage across the fleet and use that data for CI, releasing and monitoring systemd.



* Who am I + what do I work on
* The common big monitoring hole many bare bone infrastructures have
    * PID 1
    * PID 1 usage
* Systemd @ meta
    * Imaging initrd
    * Initrd
    * Main os
    * Twine containers
* Overview of OS image building and deployment @ meta
    * How we build images
    * How we provision servers
    * Chef&#8217;s role
    * What we check from our PID1 statistics to ensure a box is &#8220;healthy&#8221; enough to take workloads
* Usage of hyperscale&#8217;s systemd-cd @ meta
    * What is systemd-cd
        * [https://sigs.centos.org/hyperscale/internal/ci/](https://sigs.centos.org/hyperscale/internal/ci/)
    * How do we use it
    * What issues has it found for us
* Monitoring of meta&#8217;s systemd usage across the millions of hosts
    * Stats collected
    * Introduce monitord
        * Dbus (fun) vs. varlink
        * mention OSS alternative(s) found - explain why invented monitord
    * Introduce monitord-exporter
    * Show usage outside of meta (will be my small home infra + VPS&#8217;s)</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/7APG3H/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/7APG3H/feedback/</feedback_url>
            </event>
            <event guid='c6beb52d-b71a-5412-aec4-ae5dfc48544e' id='301'>
                <room>Main Hall</room>
                <title>Avocado Linux: Highly Secure Accelerated Embedded Development Platform for (A)IoT</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T14:30:00+02:00</date>
                <start>14:30</start>
                <duration>00:40</duration>
                <abstract>Developing embedded products often involves a trade-off between robust security and accelerated development. Production environments, while offering high security and immutability, can inhibit rapid development cycles. Conversely, sandbox environments provide the flexibility and integration needed for fast development but are not suitable for production deployment. The transition between these two environments is typically fraught with challenges, consuming significant time and effort.

This talk introduces Avocado Linux, a highly secure, image-based operating system and layer repository with deeply integrated developer tools. Avocado strikes a perfect balance between flexibility and immutability, combining the best of both worlds, accelerating time to market  without compromising on security.

By leveraging innovative systemd features like System Extensions, Configuration Extensions, and Portable Services, Avocado Linux provides a robust framework for service management, process isolation, and secure, atomic updates. Its design ensures robust security and system integrity, with comprehensive use of dm-verity and mechanisms for recovery and factory reset, safeguarding device data integrity even in the face of unexpected failures.

Join us to explore how Avocado can transform your embedded systems development with faster integration, enhanced reliability, and seamless composability. Discover how this distribution delivers significant business value by enabling rapid deployment, maintaining security, and ensuring system integrity. Learn how Avocado abstracts away the complexities of system development, allowing your team and applications to thrive and your embedded product to scale and succeed.</abstract>
                <slug>all-systems-go-2024-301-avocado-linux-highly-secure-accelerated-embedded-development-platform-for-a-iot</slug>
                <track></track>
                <logo>/media/all-systems-go-2024/submissions/QWTAFC/AvocadoOS1200_va4Y48s.gif</logo>
                <persons>
                    <person id='235'>Justin Schneck</person>
                </persons>
                <language>en</language>
                <description>About the Talk
In this talk we will explore 
* Demo use cases for building complex products
* Developer tools and workflows
* Manufacturing optimizations for provisioning and end of line testing
* In field debugging and system fault tolerance</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/QWTAFC/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/QWTAFC/feedback/</feedback_url>
            </event>
            <event guid='120b9ff9-7c55-50a3-afa2-b2dfaec752b2' id='263'>
                <room>Main Hall</room>
                <title>Boring infrastructure: Building a secure signing environment</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T15:15:00+02:00</date>
                <start>15:15</start>
                <duration>00:40</duration>
                <abstract>Many Linux distributions rely on cryptographic signatures for their packages and release artifacts. However, most of the used signing solutions either do not rely on hardware backed private key material or are run in untrusted environments.

This presentation will provide a general overview of the [Signstar](https://gitlab.archlinux.org/archlinux/signstar/) project, which is currently under development by Arch Linux to provide a generic signing solution based on a Hardware Security Module (HSM).</abstract>
                <slug>all-systems-go-2024-263-boring-infrastructure-building-a-secure-signing-environment</slug>
                <track></track>
                
                <persons>
                    <person id='152'>David Runge</person>
                </persons>
                <language>en</language>
                <description>To improve build automation and general supply chain security for Arch Linux, some of its developers have started to conceptualize and work on a generic, central signing solution: [Signstar](https://gitlab.archlinux.org/archlinux/signstar/).
In this context, related work has been evaluated for adoption, but it soon became clear, that to meet the distribution&apos;s requirements a custom solution would be implemented.

For transparency and auditability reasons Nitrokey&apos;s NetHSM has been chosen as Hardware Security Module (HSM).
Developers are actively working on a high-level Rust library and CLI to interface with the device over network.

In this presentation I will introduce the viewer to some of Arch Linux&apos;s relevant history and requirements, the evaluated architecture and setup.
Together we will have a look at Signstar&apos;s threat model, its design for minimizing credentials exposure of the HSM, as well as its integration with the OpenPGP ecosystem.
Additionally, we will explore avenues for future work on other generic cryptographic operations in the context of X.509, SSH and Secure Boot.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/WWEGGC/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/WWEGGC/feedback/</feedback_url>
            </event>
            <event guid='9d585bb0-08af-5ac7-82fa-bafbd02fca83' id='273'>
                <room>Main Hall</room>
                <title>Improving systemd&#8217;s integration testing infrastructure</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T16:30:00+02:00</date>
                <start>16:30</start>
                <duration>00:25</duration>
                <abstract>The Sovereign Tech Fund paid Codethink to help improve the integration testing infrastructure of systemd. This talk covers how the integration test suite used to work and what it does now.</abstract>
                <slug>all-systems-go-2024-273-improving-systemd-s-integration-testing-infrastructure</slug>
                <track></track>
                
                <persons>
                    <person id='217'>Sam Leonard</person>
                </persons>
                <language>en</language>
                <description>Systemd&apos;s integration test suite used to have a number of shortcomings in terms of features and maintainability.
The Sovereign Tech Fund provided an opportunity to improve things, and rewrite the test suite to use a select number of special-purpose tools and</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9JKWCT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9JKWCT/feedback/</feedback_url>
            </event>
            <event guid='eb498dbf-d3bf-5c72-87c1-9969238e7332' id='281'>
                <room>Main Hall</room>
                <title>Successes and struggles using the systemd user instance in developer environments</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T17:00:00+02:00</date>
                <start>17:00</start>
                <duration>00:25</duration>
                <abstract>This talk will explore several of the ways we&apos;ve leveraged the systemd user instance in our developer environments at Meta, challenges we faced while doing so, and how we worked around those challenges.</abstract>
                <slug>all-systems-go-2024-281-successes-and-struggles-using-the-systemd-user-instance-in-developer-environments</slug>
                <track></track>
                
                <persons>
                    <person id='223'>Colin Chan</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/H7CVUQ/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/H7CVUQ/feedback/</feedback_url>
            </event>
            <event guid='6f4f3d4f-1ad2-547c-86fb-f6ebe6d6c2f1' id='302'>
                <room>Main Hall</room>
                <title>mkosi-initrd: initrds built from system packages</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T17:30:00+02:00</date>
                <start>17:30</start>
                <duration>00:25</duration>
                <abstract>mkosi-initrd is a project to build initrds from normal system packages (rpms, debs). Initially separate, it now is part of mkosi &#8212; just another build stage. systemd uses mkosi for automated tests, and this now includes building an initrd and booting a VM with it, so such initrds are getting fairly wide testing, albeit in fairly narrow circumstances. The process of adoption of mkosi-initrd in distributions has been slow, but with an implementation natively in mkosi, the technical base is really good. What remains to be done to make this the default approach? Can Fedora 41 finally make this an option for users?</abstract>
                <slug>all-systems-go-2024-302-mkosi-initrd-initrds-built-from-system-packages</slug>
                <track></track>
                
                <persons>
                    <person id='137'>Zbigniew J&#281;drzejewski-Szmek</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/JTXJR7/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/JTXJR7/feedback/</feedback_url>
            </event>
            <event guid='f4ef97aa-2e5e-5507-915f-e2ac36642e9f' id='291'>
                <room>Main Hall</room>
                <title>initrd performance improvements</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T18:00:00+02:00</date>
                <start>18:00</start>
                <duration>00:25</duration>
                <abstract>Every second spent on waiting for a system to boot is wasted time. In this talk I present the steps we took in Ubuntu to speed up the boot and the initrd generation time. The presented improvements are not specific to Ubuntu and can be ported to other implementations (like dracut) to benefit other distributions as well. The talk will present further speed improvements that can/will be implemented in the future. That includes rewriting parts in modern languages like Rust.</abstract>
                <slug>all-systems-go-2024-291-initrd-performance-improvements</slug>
                <track></track>
                
                <persons>
                    <person id='229'>Benjamin Drung</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9T8LTT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/9T8LTT/feedback/</feedback_url>
            </event>
            <event guid='25d1f374-8321-5c35-9666-c6a236b3ca92' id='319'>
                <room>Main Hall</room>
                <title>Closing session of All Systems Go! 2024</title>
                <subtitle></subtitle>
                <type>Lightning talk</type>
                <date>2024-09-26T18:25:00+02:00</date>
                <start>18:25</start>
                <duration>00:05</duration>
                <abstract>Closing session of All Systems Go! 2024</abstract>
                <slug>all-systems-go-2024-319-closing-session-of-all-systems-go-2024</slug>
                <track></track>
                
                <persons>
                    
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/DLUVHF/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/DLUVHF/feedback/</feedback_url>
            </event>
            
        </room>
        <room name='Dome' guid='7fc98a2b-9ada-5cda-ab77-97c74395cf6b'>
            <event guid='e8d9b650-1021-5bf5-b076-f5cbfbd1cd6f' id='296'>
                <room>Dome</room>
                <title>Reproducible Builds at Sidero Labs: Tools and Techniques</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T09:30:00+02:00</date>
                <start>09:30</start>
                <duration>00:25</duration>
                <abstract>Ensuring consistent and secure software builds is crucial in today&apos;s cloud-native environments. At Sidero Labs, we&apos;ve developed a comprehensive approach to reproducible builds for Talos Linux using a variety of tools and techniques. This talk will explore our use of Docker Buildx, Kres, and other key components that contribute to our build system. We&apos;ll share insights into our methods, challenges faced, and solutions implemented, providing practical guidance for developers aiming to achieve reproducibility in their own projects.</abstract>
                <slug>all-systems-go-2024-296-reproducible-builds-at-sidero-labs-tools-and-techniques</slug>
                <track></track>
                
                <persons>
                    <person id='234'>Utku &#214;zdemir</person>
                </persons>
                <language>en</language>
                <description>To achieve a fully reproducible stack, from the kernel and initramfs to the software we own and third-party software we build, we use multiple tools in our toolset:

- Buildx: Provides a consistent environment for building software.
- Kres: Our project scaffolding tool for generating and updating build instructions and dependencies.
- Code Patches: Address issues in third-party projects that prevent reproducible builds.
- Tests: Written by us to ensure and verify reproducibility.

In this talk, we will cover each of these tools and techniques, providing examples and practical insights. You will learn how to apply these methods to achieve reproducible builds in your own projects, gaining a complete picture of our approach and how it can be adapted to your needs.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/RYZJ9W/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/RYZJ9W/feedback/</feedback_url>
            </event>
            <event guid='a979bfcf-2a0f-58ab-bc43-ce5b56528d26' id='305'>
                <room>Dome</room>
                <title>using io_uring for storage</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T09:55:00+02:00</date>
                <start>09:55</start>
                <duration>00:25</duration>
                <abstract>A brief report about how we use io_uring in SLASH/fellow https://gitlab.com/uplex/varnish/slash, an always consistent, eventually persistent storage engine for Varnish-Cache. (FOSS, LGPL)</abstract>
                <slug>all-systems-go-2024-305-using-iouring-for-storage</slug>
                <track></track>
                
                <persons>
                    <person id='238'>Nils Goroll</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/U7GJJW/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/U7GJJW/feedback/</feedback_url>
            </event>
            <event guid='998602c0-3c2c-55d0-b533-5791a058c01a' id='310'>
                <room>Dome</room>
                <title>libpathrs: securing path operations for system tools</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T10:20:00+02:00</date>
                <start>10:20</start>
                <duration>00:25</duration>
                <abstract>Container runtimes and other privileged system management tools have historically struggled with safely operating on a path within a directory tree controlled by a malicious user. [libpathrs][] is a library which makes it easy to do said path operations, as well as providing some other safe path-related utilities such as providing safe wrappers to operate on procfs files in a safe way.

[libpathrs]: https://github.com/openSUSE/libpathrs</abstract>
                <slug>all-systems-go-2024-310-libpathrs-securing-path-operations-for-system-tools</slug>
                <track></track>
                
                <persons>
                    <person id='86'>Aleksa Sarai</person>
                </persons>
                <language>en</language>
                <description>As part of the kernel work on openat2(2) and continuing kernel work to make magic-links safer (against both confused deputy attacks and resource re-opening attacks), the need for a library to make it easy to do all sorts of VFS operations safely became obvious, and so [libpathrs][] was born. [libpathrs][] uses openat2(2) if available, but has a fallback to the old fashioned (and more finicky) method of doing safe-ish path resolutions.

This talk will talk about how [libpathrs][] works and how it can help secure container runtimes and privileged system management tools against attacks, as well as touching on some ongoing kernel work which would allow for even more hardening.

After the talk, slides will be available from [my site](https://www.cyphar.com/talks).

[libpathrs]: https://github.com/openSUSE/libpathrs</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/ZZFL7L/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/ZZFL7L/feedback/</feedback_url>
            </event>
            <event guid='404a2e35-a801-5554-a9d2-fa10b2045781' id='274'>
                <room>Dome</room>
                <title>Booting an embedded system like a PC</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T10:50:00+02:00</date>
                <start>10:50</start>
                <duration>00:40</duration>
                <abstract>This shows how to boot an [mkosi](https://github.com/systemd/mkosi) generated arm64 [Debian](https://debian.org) Image with [UKI](https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md) and systemd-boot on a [u-boot](https://docs.u-boot.org/en/latest/develop/uefi/u-boot_on_efi.html) based EFI firmware with a [fTPM](https://github.com/microsoft/ms-tpm-20-ref/tree/main/Samples/ARM32-FirmwareTPM/optee_ta/fTPM) as a Trusted-Application in [OP-TEE](https://optee.readthedocs.io/en/latest/general/about.html)</abstract>
                <slug>all-systems-go-2024-274-booting-an-embedded-system-like-a-pc</slug>
                <track></track>
                
                <persons>
                    <person id='218'>Manuel Traut</person>
                </persons>
                <language>en</language>
                <description>Embedded systems are very similar to IT managed PCs. A manufacturer of the device wants to ensure, that the system integrity is good, e.g. before unlocking secrets that allow accessing cloud services.

Therefore the recent developments of the UAPI group and systemd are also very useful in the embedded world.

This talk gives an overview of the involved software components and how they are combined.
It shows how to build a firmware for an i.MX8MM that allows booting modern Linux images.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/VZGAAG/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/VZGAAG/feedback/</feedback_url>
            </event>
            <event guid='42c0ee40-573c-5172-837f-c99413445666' id='267'>
                <room>Dome</room>
                <title>Building Secure Container Images for the Cloud with Yocto</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T11:35:00+02:00</date>
                <start>11:35</start>
                <duration>00:40</duration>
                <abstract>Yocto is a tool for building custom Linux distros. When you think about it, a container image is just a custom Linux distro. The distro (e.g. Alpine) is your base image and the customizations are the rest of your application or microservice. Like Podman, Yocto can generate a complete root filesystem in the form of an OCI container image. Originally targeted at bare metal, the Yocto configuration and build process seems complex when compared to the Containerfile approach of cloud native tools. Yocto&apos;s OpenEmbedded origins also mean that reduced image size, SBOM generation, license compliance, and reproducible builds were concerns early on in the project rather than afterthoughts. With security and risk of litigation now top of mind, this talk explains Yocto&apos;s uniquely layered and ultimately monolithic approach to solving these real-world software problems.</abstract>
                <slug>all-systems-go-2024-267-building-secure-container-images-for-the-cloud-with-yocto</slug>
                <track></track>
                
                <persons>
                    <person id='212'>Frank Vasquez</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/KZPRPN/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/KZPRPN/feedback/</feedback_url>
            </event>
            <event guid='9b5213ab-3052-597b-8727-a6eb2761ff41' id='253'>
                <room>Dome</room>
                <title>Removing Cloud Providers From the Zero Trust Equation</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T12:20:00+02:00</date>
                <start>12:20</start>
                <duration>00:40</duration>
                <abstract>This presentation introduces a novel approach to enhance the trust in SPIFFE by leveraging confidential computing technologies, specifically Confidential Virtual Machines.
The presentation will provide an introduction to the realm of confidential computing, as well as an overview of SPIFFE/SPIRE. Armed with this knowledge we will demonstrate a practical example that integrates the AWS Instance Identity Document plugin with AMD SEV-SNP, showcasing the implementation challenges and solutions.</abstract>
                <slug>all-systems-go-2024-253-removing-cloud-providers-from-the-zero-trust-equation</slug>
                <track></track>
                
                <persons>
                    <person id='202'>Fabian Kammel</person>
                </persons>
                <language>en</language>
                <description>SPIFFE is a framework to generate identities for software systems in dynamic and heterogeneous environments. SPIFFE Verifiable Identity Documents (SVIDs) enable us to be explicit about the trust we place in systems. However, the degree of trust we can place in SVIDs relies heavily on the soundness of the data gathering and verification process during node attestation.

This presentation introduces a novel approach to enhance the trust in SVIDs by leveraging confidential computing technologies, specifically Confidential Virtual Machines (CVMs) such as AMD SEV-SNP or Intel TDX. These technologies enable us to track platform information directly in hardware, including firmware, boot loader, and kernel images, which are then signed with a key rooted inside the CPU itself. By incorporating hardware-protected platform information directly into the SVID generation process, we can significantly enhance the confidence placed in the resulting identity documents. Additionally, consumers of these SVIDs will be able to assert these properties before placing trust in a system.

The presentation will provide an introduction to the realm of confidential computing, as well as provide an overview of SPIFFE/SPIRE, including the architecture of SPIRE agents and servers, the concept of workloads and SPIFFE SVIDs, and the role of node plugins in the attestation process. A practical example that integrates the AWS Instance Identity Document plugin with AMD SEV-SNP will be demonstrated, showcasing the implementation challenges and solutions.

Through this presentation, attendees will gain insights into how confidential computing technologies can bolster the security of critical systems in an untrusted cloud environment, paving the way for more robust and resilient infrastructure in modern computing environments.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/AG7L3K/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/AG7L3K/feedback/</feedback_url>
            </event>
            <event guid='a568f198-98a8-539b-8bb6-e761e4989d9e' id='298'>
                <room>Dome</room>
                <title>busd: There is a new D-Bus broker in town</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T14:30:00+02:00</date>
                <start>14:30</start>
                <duration>00:40</duration>
                <abstract>D-Bus is an IPC mechanism that is very ubiquitous on Linux systems everywhere (desktop, cloud and embedded). It is the mechanism you&apos;d use to communicate with many of the core Linux userspace subsystems, such as systemd, NetworkManager etc. Traditionally, most of these services have been written in C, a language known for its lack of safety and expressiveness.

In the past years, Zeeshan has developed a library, called zbus for enabling implementation of D-Bus services and clients in a programming language designed for safety: Rust. zbus has become the go-to library for writing D-Bus code in Rust. While that is major step forward, the communication typically still happens through a broker and the two major broker implementation are both are written in C and have been stagnating for years.

This is why Zeeshan has recently started working on writing a D-Bus broker based on zbus, called busd, which not only aims provide a drop-in replacement for existing brokers, but also modernize the D-Bus space by providing new features needed by apps and services, such as systemd.

In this talk, Zeeshan will walk us through a summary of his journey so far, the current state of busd and his plans and dreams for the future of D-Bus.</abstract>
                <slug>all-systems-go-2024-298-busd-there-is-a-new-d-bus-broker-in-town</slug>
                <track></track>
                <logo>/media/all-systems-go-2024/submissions/WB7DYF/busd-logo_cCPaG3F.png</logo>
                <persons>
                    <person id='4'>Zeeshan Ali Khan</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/WB7DYF/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/WB7DYF/feedback/</feedback_url>
            </event>
            <event guid='749da409-6d51-53b9-a19a-4e90b5c0672d' id='320'>
                <room>Dome</room>
                <title>SSH authentication using user and machine identities</title>
                <subtitle></subtitle>
                <type>35 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T15:15:00+02:00</date>
                <start>15:15</start>
                <duration>00:40</duration>
                <abstract>Strong authentication requires multiple signals: identity claims proves that identity of the person, while device attestation proves possession of a given machine, and device bound keys prevent the key from being stolen.

In this presentation we will take a look at how the TPM provides device attestation and device bound keys. We will connect this with identity claims from SSO providers to provide a centrally managed short-lived SSH certificates for users and their devices. This is implemented as an open-source project called &#8220;ssh-tpm-ca-authority&#8221;.</abstract>
                <slug>all-systems-go-2024-320-ssh-authentication-using-user-and-machine-identities</slug>
                <track></track>
                
                <persons>
                    <person id='257'>Morten Linderud</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/JCJ9YT/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/JCJ9YT/feedback/</feedback_url>
            </event>
            <event guid='e738b363-229c-594e-a21a-5560bb997825' id='283'>
                <room>Dome</room>
                <title>Installing your OS with systemd-repart</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T16:30:00+02:00</date>
                <start>16:30</start>
                <duration>00:25</duration>
                <abstract>There&apos;s a new installer for GNOME OS, and it&apos;s built on top of systemd-repart. Here&apos;s how and why we did it</abstract>
                <slug>all-systems-go-2024-283-installing-your-os-with-systemd-repart</slug>
                <track></track>
                
                <persons>
                    <person id='194'>Adrian Vovk</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/CMQTNL/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/CMQTNL/feedback/</feedback_url>
            </event>
            <event guid='a860711f-14c4-5356-92ec-2cb976444e3d' id='285'>
                <room>Dome</room>
                <title>GNOME OS + systemd-sysupdate</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T17:00:00+02:00</date>
                <start>17:00</start>
                <duration>00:25</duration>
                <abstract>As a reference for developers and testers, GNOME OS is an experimental Linux distribution that ships the latest in-development GNOME desktop, core applications, and stack. 

GNOME OS is currently using OSTree, this talk covers the ongoing work to add features to systemd-sysupdate and transition to it. Features like optional transfers, delta updates, and major version upgrades.</abstract>
                <slug>all-systems-go-2024-285-gnome-os-systemd-sysupdate</slug>
                <track></track>
                
                <persons>
                    <person id='225'>Abderrahim Kitouni</person><person id='240'>Jude Onyenegecha</person>
                </persons>
                <language>en</language>
                <description>GNOME OS is an experimental Linux distribution that ships the latest in-development GNOME desktop, core applications, and stack. It serves as a reference for developers and testers. This operating system is designed and built around the modern systemd and GNU-based userland built from the Freedesktop SDK.

Currently, GNOME OS uses OSTree to deploy the root filesystem and manage updates. This means that the base OS is immutable (read-only) and updates can be quickly downloaded as deltas. OSTree allows easy rollback to multiple previous versions of the root filesystem, which is essential for a testing-first distribution focused on finding bugs.

Our work focuses on transitioning GNOME OS to use systemd-sysupdate. Migrating to sysupdate would bring the following benefits:
* Provide a trust chain from the bootloader, all the way up, both online and offline;
* Achieve a closer integration with systemd;
* Advance our support for image-based design and its benefits, e.g., immutability, auto-updating, adaptability, factory reset, uniformity and other modernised security properties around image-based OSes.

For that, we are adding a number of features to systemd-sysupdate to make it more production ready; 
* Implement optional transfers in systemd-sysupdate
* sysupdate should allow upgrading to a newer major version
* pluggable backends for systemd-sysupdate (or systemd-import)

This project was partly inspired by Lennart Pottering&apos;s article &quot;Brave New Trusted Boot World&quot;, in which he explains a vision of the future of Linux systems.</description>
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/MGDHYQ/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/MGDHYQ/feedback/</feedback_url>
            </event>
            <event guid='ef2495ce-b728-5d01-8b8b-4e788f44452d' id='282'>
                <room>Dome</room>
                <title>Home Directory Encryption in GNOME</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T17:30:00+02:00</date>
                <start>17:30</start>
                <duration>00:25</duration>
                <abstract>Thanks to work made possible by the STF grant, all the pieces are there for GNOME to integrate with systemd-homed. This talk describes what it took to get here, what new features it gives us, what still remains to be done</abstract>
                <slug>all-systems-go-2024-282-home-directory-encryption-in-gnome</slug>
                <track></track>
                
                <persons>
                    <person id='194'>Adrian Vovk</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFY3BB/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/FFY3BB/feedback/</feedback_url>
            </event>
            <event guid='b21d8933-5766-5d6f-b39b-aac1c4e765ae' id='297'>
                <room>Dome</room>
                <title>Can systemd-resolved replace Avahi?</title>
                <subtitle></subtitle>
                <type>20 min talk + 5 min Q&amp;A</type>
                <date>2024-09-26T18:00:00+02:00</date>
                <start>18:00</start>
                <duration>00:25</duration>
                <abstract>Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), collectively know as zeroconf, are technologies used for devices to find each other and advertise services on the local network.

There are two widely used FOSS implementations: mDNSResponder is used by Apple and Android, while Avahi is used by most GNU/Linux distributions. However, there is a third one in systemd-resolved -- widely installed but rarely used.

In this talk, I will explain how mDNS and DNS-SD work individually and together, and explore how to use them with resolvectl. I&apos;ll also try to go over the deficiencies in the systemd-resolved and have a discussion about the ways that it can be improved to replace Avahi as the default implementation on GNU/Linux systems.</abstract>
                <slug>all-systems-go-2024-297-can-systemd-resolved-replace-avahi-</slug>
                <track></track>
                
                <persons>
                    <person id='225'>Abderrahim Kitouni</person>
                </persons>
                <language>en</language>
                
                <recording>
                    <license></license>
                    <optout>false</optout>
                </recording>
                <links></links>
                <attachments></attachments>

                <url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/C3DZDS/</url>
                <feedback_url>https://cfp.all-systems-go.io/all-systems-go-2024/talk/C3DZDS/feedback/</feedback_url>
            </event>
            
        </room>
        
    </day>
    
</schedule>
