
Chaos Computer Club - archive feed
21,021 episodes — Page 91 of 421
Wolfi: A Secure-by-Default Distro for Curing Container CVE Chaos (asg2023)
mkosi: Building Bespoke Operating System Images (asg2023)
mkosi is a tool for building operating system images. In this talk we'll give an introduction to mkosi, how we use it to develop systemd and discuss how we want to support running and updating systems with mkosi and other systemd tooling. Github repository: https://github.com/systemd/mkosi/ Initial blog post on mkosi: https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ASV8ZM/
mkosi: Building Bespoke Operating System Images (asg2023)
openSUSE Aeon - Desktop Linux finally done right? (asg2023)
openSUSE Aeon (formerly MicroOS Desktop) aims to be a fully fledged modern Linux Desktop leveraging as many of the latest user space innovations available including: - Immutable OS with Transactional Updates - Secure Boot - TPM Encryption - Flatpaks & OCI containers as primary application delivery This talk will introduce the distribution, highlight the adoption of some of the latest foundational user space technologies as well as share some of the pain points being faced and invite the audience to contribute to this exciting platform. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/RV3UZD/
openSUSE Aeon - Desktop Linux finally done right? (asg2023)
Exploring RAUC: A Flexible Building Block for Image-Based Updates (asg2023)
Exploring RAUC: A Flexible Building Block for Image-Based Updates (asg2023)
Recently, atomic updates via image based systems have become more relevant for servers and desktops, as they allow predictable management of large fleets. In the embedded Linux space, this approach has been the default for many years and proven updaters exist already. In this talk, we will delve into RAUC and look at how its design and features have been driven by the requirements for robust, atomic updates. The presentation will introduce the fundamental concepts surrounding A/B fallback and update signing in the context of embedded Linux updates. We will then explore the commonalities and differences between RAUC and systemd's sysupdate. The discussion will progress to cover RAUC's bundle-based update system, which allows for comprehensive system updates without the need for local storage, thanks to HTTP streaming. Additionally, we will demonstrate how adaptive updates minimize download sizes without necessitating version-specific patch management. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/NEQ9TX/
Replica.one: A Software-defined Operating System (asg2023)
Network operating systems commonly provide a stable userspace platform for networking devices. Integration of userspace applications as well as low-level hardware support are handled by firmware build systems. Existing build systems for network operating systems display numerous limitations by either targeting only distinct types of devices, using cumbersome methodologies to add additional features or offering insufficient capabilities regarding what to include in the firmware image. In this presentation, we provide an overview of these limitations and how we mitigate them with Replica.one, an Open Source firmware builder which targets the entire networking stack. We will focus on the solution's optimization features, its capability to generate firmware for diverse classes of devices across the entire networking stack, and the flexibility to select the desired operating system between various Linux-based distributions. The presentation targets Linux users who are interested in replacing their existing build system infrastructure with a single unified software platform. The flexibility of image-based network operating systems will allow organizations and its users to operate their existing hardware resources more efficiently and securely. Professionals who are working in the domain of firmware build systems to integrate applications and features will benefit from Replica.one’s ease of use as well as powerful image customization capabilities. The novel element of a single platform running on an entire networking infrastructure stack will be of particular interest to a wide range of organizations and companies looking to reduce their operating cost while reaping the benefits of open source community effort. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/LBWXKL/
systemd-repart: Building Discoverable Disk Images (asg2023)
Replica.one: A Software-defined Operating System (asg2023)
systemd-repart: Building Discoverable Disk Images (asg2023)
systemd-repart has recently learned many features to make it useful for building discoverable disk images. In this talk, we'll give a deep-dive on the new features and how they can be used to assemble discoverable disk images. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/VPQADA/
A/B partitioning - let's talk about the dirty RW files (asg2023)
A/B partitioning - let's talk about the dirty RW files (asg2023)
A/B partitioning is great - you hermetically drop-in the whole new OS and boot into it. Although, how can we manage and migrate the RW configuration and state files that lie within? Can we do that reliably on both OS upgrades and downgrades? This talk will explore the design used on the SteamDeck, the issues we've seen while drawing analogies, and future inspiration with "Fitting Everything Together" by Lennart Poettering in mind. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/MPAEFK/
Oxidizing the Arch Linux packaging infrastructure (asg2023)
Arch Linux has worked with its own packaging framework - Arch Linux Package Management (ALPM) - for about 20 years. This talk is about an effort to rewrite low-level components and to create specifications for related metadata files using the Rust programming language. It will cover new projects in the ALPM (https://gitlab.archlinux.org/archlinux/alpm/) group as well as several other related ones and give an outlook on future developments using the 🦀 Arch Linux (https://archlinux.org) has worked with its own packaging framework - Arch Linux Package Management (ALPM) - for about 20 years. The tooling consists mainly of scripts for package creation (e.g. `makepkg`, written in Bash) and a package manager (`pacman`, written in C). Over the last years several projects for the improvement of the packaging and package distribution ecosystem have been started. Some of which had to reinvent the wheel. This talk is about an effort to rewrite low-level components and to create specifications for related metadata files using the Rust programming language. It will cover new projects in the ALPM (https://gitlab.archlinux.org/archlinux/alpm/) group as well as several other related ones and give an outlook on future developments using the 🦀 about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/3LES8Z/
Oxidizing the Arch Linux packaging infrastructure (asg2023)
A story of a bootloader^W^Wthree bootloaders (asg2023)
This talk will explore the ideas from Lennart's "Fitting Everything Together" blog post, particularly the A/B partitioning scheme and its bootloader design, comparing it with the approach used on the SteamDeck. Spoiler alert, we're not using sd-boot. We will focus on the requirements that drove us to the latter design, some implementation details, and hurdles we needed to overcome to achieve that project. Lastly, the idea of finding common ground will be entertained where audience participation is greatly encouraged. What features would be acceptable by the wider systemd community? Would those be enough for the SteamDeck to jump ship? about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/SMQPWM/
A story of a bootloader^W^Wthree bootloaders (asg2023)
Kernel command line and UKI; systemd-stub and the ‘stubby’ alternative (asg2023)
Fast, correct, reproducible builds with Nix + Bazel (asg2023)
Fast, correct, reproducible builds with Nix + Bazel (asg2023)
The build system should get out of the way to let us focus on our tasks, not be distracted by slow or unreliable builds, get fast feedback on changes, and let us know what’s in the software we’re shipping to our users. But, what does it take for a build system to be really fast and reliable? What does it take to know what’s in the software? It requires aggressive parallelism and distributed caching to avoid redundant work between colleagues. And it requires complete knowledge and control of dependencies, build isolation to identify mistakes, and reproducible builds to verify results across machines and strengthen supply-chain security. In this talk you will learn how [Google’s open source build system Bazel](https://bazel.build/) and the [purely functional package manager Nix](https://nixos.org/) join forces to provide fast, correct, and reproducible builds. In this talk I will explain what we mean by correct builds, and will motivate why fast and correct builds are important and why you would care about reproducible and isolated builds. We will see how many common build systems fail to provide these desirable properties. You will be introduced to [Google’s open source build system Bazel](https://bazel.build/) and will learn how it provides fast builds, how correctness and reproducibility is relevant, and how Bazel tries to ensure correctness. But, we will also see where Bazel falls short in ensuring correctness and reproducibility. You will learn about the [purely functional package manager Nix](https://nixos.org/) and how it approaches correctness and build isolation. And we will see where Bazel has an advantage over Nix when it comes to providing fast feedback during development. I will share how you can get the best of both worlds and combine Nix and Bazel and how you can get started with these tools. But, we will also touch on potential caveats and shortcomings of this approach. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/77YDZ8/
Kernel command line and UKI; systemd-stub and the ‘stubby’ alternative (asg2023)
Modification of the kernel command line has historically been one of the easiest ways to customize system behavior. Bootloaders allow for persistent changes via config-files and on-the-fly changes interactively during system boot. System behavior changes made via the kernel command line are not limited to the kernel itself. Userspace applications from installers to init systems and beyond also take input from /proc/cmdline. It is clear that some kernel command line options are desirable (console=ttyS0 verbose) and possibly even necessary. Others, such as the cromulent 'init=/bin/sh', can allow circumvention of benefits that Secureboot and TPM provide. How to control access to kernel command line modification is a non-trivial subject. A recent pull request to systemd that added "command-line addons" garnered hundreds of comments. This talk will cover: * The stub loader 'stubby' and its allowed-list approach to kernel command line options. * Systemd-stub’s solution for command line customization * System changes that can be made through kernel command line. * Alternative channels such as smbios oem strings, or qemu 'fw_cfg' about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/T3QFGS/
systemd-boot integration in openSUSE (asg2023)
openSUSE is a general purpose, rpm based distribution. One of it's unique features is the use of btrfs snapshots to offer rollback of the root file system of both traditional as well as transactional systems. This talk explains the challenges faced to integrate systemd-boot into openSUSE. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/E9NVZE/
systemd-boot integration in openSUSE (asg2023)
Writing your own NixOS modules for fun and (hopefully) profit (asg2023)
Writing your own NixOS modules for fun and (hopefully) profit (asg2023)
This talk will be a whirlwind overview of NixOS modules and the lessons I've learned with maintaining and writing new ones. Nix modules are the core of how you organize configuration and service config, but there's a lot of "draw the rest of the owl" subtext as to how you actually go about writing them. This talk covers some best practices for how to write and organize your NixOS modules so that you can have fun and hopefully profit from it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/DP3JXQ/
Talos Linux - TrustedBoot for a minimal Immutable OS (asg2023)
The Talos Linux distribution is built from scratch with the goal of providing a secure, verified, and minimal-footprint operating system for running Kubernetes clusters. Talos is designed to be immutable, minimal, and secure. Talos includes only the bare minimum required to run Kubernetes. This talk will cover how Talos uses Unified Kernel Images (UKIs) to provide immutable, verified, and secure booting. We will also cover how Talos partially conforms to the Linux Userspace API Group specification (UAPI) to implement some of the best practices with regards to fully verifiable TrustedBoot extending to the userspace. With the upcoming Talos 1.5 release, Talos ships with custom ISO and metal images that are UKI compliant. This means that the kernel, initramfs, and the root filesystem are all signed and verified by the bootloader. This allows Talos to provide a fully verified boot process from the bootloader to the userspace attested by TPM. This talk will cover the following topics: - Building UKI (ukify.py implementation in Go) - Issues with reproducibility - sd-boot - sd-stub - Upgrades/Rollbacks - systemd-measure and systemd-cryptenroll partial implementation in Go Future work: - IMA attestations for userspace runtime binaries (etcd, kubelet, containerd, etc) - Talos system extensions as sd-stub compatible sysexts - Kexec with Secureboot (how can we verify the TPM PCR values are populated correctly with values from new UKI) about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/Q9YBUZ/
Trusted, Confidential and Cloud Native Workloads. An intro to the Confidential Containers project (asg2023)
The talk wants to provide a brief introduction into Confidential Containers Project. We'll discuss the rationale behind Confidential Computing and how concepts like Trusted Computing or Remote Attestation can be leveraged by end-users to guard their workloads not only from malicious actors but also their cloud service provider. Confidential Containers, an open-source CNCF project, aims to extend the experience of deploying cloud-native software on Kubernetes with the option to move sensitive workloads into confidential enclaves with minimal friction to the user experience. We'll introduce the components and container technologies we are using to achieve that, hint at some conceptual problems we are facing and provide a simple example of how confidential containers work in practice today. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/GFDUHW/
Talos Linux - TrustedBoot for a minimal Immutable OS (asg2023)
Adventures of Linux Userspace at Meta (asg2023)
Adventures of Linux Userspace at Meta (asg2023)
The Linux Userspace team at Meta aims to make significant contributions to upstream userspace projects, while also ensuring that Meta is able to leverage those improvements. In this talk we'll give an overview of the team and brief history of how it was formalized. Then we'll dive deeper into some of the efforts we've worked on with the open source community and features we've adopted internally. Come if you enjoy hearing about systemd, BPF, distributions, and more! about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/YAHVZG/
Confidential Compute: State-of-the-art and how to get started (asg2023)
Confidential compute is a new compute and programming paradigm to run an application in enclave, a run-time encrypted and authenticated trusted execution environment. We give an overview of the current technologies provided by AMD, Intel and ARM. We also give an overview of open source tools to leverage compute along a tutorial to enclave any applications with few command lines. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/7LVG99/
Confidential Compute: State-of-the-art and how to get started (asg2023)
Carbon OS + homed (asg2023)
All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/8P7XKH/
Carbon OS + homed (asg2023)
tvix-store (asg2023)
All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/AKNDS3/
tvix-store (asg2023)
Attaching CPUs via USB (asg2023)
All Systems Go! lightning talk about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/VAY88J/
Attaching CPUs via USB (asg2023)
Principle of least configuration (asg2023)
The journey of developing a Linux platform to require very little in the way of configuration management, and how to virtually eliminate the need to modify code to change configuration. From configuration via scripts and evolving through a couple of configuration management products, we have used the idea of matching actions to timescales to transform how we do configuration management. We now do very little of it, and we have dramatically reduced its complexity. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/PVJQTH/
Principle of least configuration (asg2023)
PID FD-ize all the things! (asg2023)
A quick overview of the work in progress to plumb PID FDs through Linux userspace, to achieve resilience and security improvements Process ID File Descriptors were introduced in Linux v5.3. They allow tracking a process reliably, without risking races and reuse attacks, as they always refer to one single process regardless of the actual PID, so if the process goes away the file descriptor will become invalid, even if a new process with the same PID reappears at the same time. Tracking processes in userspace is needed for various purposes, for example to authenticate actions via Polkit. This has been historically fragile, and various workarounds such as tracking a PID plus a UID plus a start time were put in place. D-Bus implementations also have methods to query a D-Bus' endpoint's PID, UID and GIDs. Recently work has been done to plumb PID FDs through all these components - systemd is able to receive queries asking for the session information or unit information via a PID FD, D-Bus implementations return the PID FD of a D-Bus endpoint via GetConnectionCredentials()/GetConnectionUnixProcessFD() (and they track processes via FD rather than PID), and Polkit allows writing rules authorizing by the systemd service name, which is possible to do safely thanks to using FDs all the way through. This lightning talk will quickly go through these improvements, showing how PID FDs can be used to improve userspace and provide concrete benefits. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/T3LJAM/
PID FD-ize all the things! (asg2023)
Casync is not dead, or how I learned to love desync (asg2023)
Image based OS updates are the future. One way to handle updates is via content-addressable synchronisation software, like casync and desync. This talk with give a presentation about the two - their overall design, feature set and strengths and weaknesses. It will also demonstrate a real world use-case of them. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/9MVYFU/
Casync is not dead, or how I learned to love desync (asg2023)
64-bit time_t on armhf: Running abi-compliance-checker on all of Ubuntu (asg2023)
Some quick numbers and maybe curiousities from our work on evaluating which libraries need to be rebuilt for 64-bit time_t on armhf in Ubuntu using abi-compliance-checker. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/R3SWBQ/
64-bit time_t on armhf: Running abi-compliance-checker on all of Ubuntu (asg2023)
Making a magic deduplicating tar using the FICLONE ioctl (asg2023)
A walkthrough of an interesting use case for the `FICLONE` ioctl: cloning file data into a tar archive, and cloning files out of it again. "Free" archiving and unarchiving at zero-copy speeds! Topics: - Copy-on-write and the `FICLONE` ioctl - The ancient `tar` format - A trick for adding arbitrary padding to the `tar` format in order to force file system page alignment - How to avoid symlink attacks and other TOCTOU issues, using the fairly recently introduced (linux 5.6) `openat2` system call. - An interesting bug in GNU tar At the end you'll receive a free autographed copy of [deduptar](https://git.sr.ht/~nullenenenen/deduptar/tree/master/item/README.md) to use for party tricks. 🥳 about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/99PZDY/
Y2038: replace utmp with logind (asg2023)
Making a magic deduplicating tar using the FICLONE ioctl (asg2023)
Y2038: replace utmp with logind (asg2023)
The utmp implementation of glibc uses on quite some 64bit architectures a 32bit time variable, which leads to an overflow on 03:14:07 UTC on 19 January 2038. This talk will explain the current work on replacing utmp with logind. The year 2038 problem (also known as Y2038) is a time formatting bug on Unix systems with representing times after 03:14:07 UTC on 19 January 2038. This happens with a 32bit time_t, not with a 64bit time_t. The general statement so far has always been that on 64bit systems with a 64bit time_t you are safe with respect to the Y2038 problem. But this isn't correct: on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries) glibc defines __WORDSIZE_TIME64_COMPAT32, which leads to the fact, that struct utmp (used for utmp, wtmp and btmp) and struct lastlog uses int32_t instead of time_t. So we have a Y2038 problem, which is not easy fixable, as this would require ABI and on disk format changes. In this talk I will speak about the background, which tools are affected and a radical solution: drop utmp, wtmp, btmp and lastlog completely and make use of systemd-logind and other tools instead. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/3Z7XEE/