Chaos Computer Club - archive feed

A short case study on where we are with sandboxing APT; what gaps there are and what technologies we looked at. Downloading packages, verifying packages, installing packages, protecting user data from snoopy or broken maintainer scripts. A package manager has a lot of places that can need some sort of sandboxing. APT currently employs a minimal sandbox using a separate user for downloading, and optionally seccomp. This talk will explore that, the caveats and some more avenues like landlock, running apt in systemd isolation (useful for our apt-based .service units), file descriptor passing into sandbox. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/8CGF9L/

In light of the climate crises, and despite hardware getting faster and faster, fully powering down systems and back on on demand – the obvious choice – is still inconvenient, as boot times are still very long. Even ChromeOS still has not lowered its limit from ten seconds since years. Show the current status of the hobby project on x86 hardware, and give an overview of recent Linux kernel developments getting rid some of the delays. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HZY3K8/

Despite being ordinary computers with an ASIC for switching, in reality network hardware must still be treated differently from normal servers. In recent years a lot has improved, and vendors offer white box switches, allowing users to install a (network) operating system of their choice. Of course, the NOS needs to support the firmware interface for the particular ASIC, and this is not standardized: swtitchdev, DSA, SAI – none of them supporting all devices. Due to SONiC dominance, a lot of vendors seem to support SAI (Switch Abstraction Interface). But SAI requires a proprietary external Linux kernel module. On the NOS side, Open Network Linux was abandoned, and Azure’s SONiC is the new popular kid on the block, running a Docker daemon. There are other differences in the network hardware ecosystem: For example ONIE as the bootloader environment. Also working with upstream and using established software developing practices are lacking, resulting in a maintenance burden. Projects like DENT or OpenWrt go one step further by only supporting upstream Linux kernel interfaces, but now dentOS is also going to support SAI. This talk gives a short introduction into the network operating systems, and then focuses on DENT with the ONL fork dentOS, and shares experiences. Curiously, problems how to treat firmware blobs and discussions about what distribution to use as a base, are not unknown to these projects either. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/JVGVHG/

The TPM event log contains a history of all measurements made with the TPM. Complete with some context information for each measurement it is intended to help with recreating the current PCR contents. What was meant as a debugging tool turns out to be of vital importance when trying to remotely attest real life systems. This is mostly because of the overuse of certain PCR and the general mess that is x86 firmware. Sadly, there are many event logs. UEFI keeps one for its measurements and those done by EFI applications like GRUB and shim. If a system is booted in an MLE using tboot the ACM firmware code also maintains an event log that can be accessed via a pointer in an ACPI table. Now, systemd also has an event log that is mixed into the general journal log. Finally Linux IMA maintains it's own event log -- an append-only, in-kernel data structure. On top of that every bootloader or userspace application that wants to measure something into the TPM will also need to maintain an event log. How about we fix that? The talk will sketch out a solution that maintains a unified, global event log of the whole system on disk and exposes an interface for other applications that wish to measure things into the TPM. We'll also fix a race conditions in IMA as well as correctly handle S3 resume w.r.t measured boot while we're at it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HGMV9U/

Let's get you up to speed on Trusted Platform Modules (TPM 2.0) and Linux. Specifically, the various additions to basic Linux userspace, i.e. systemd in our goal to make measured boot a default on Linux. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HSEJY9/

This talk will discuss new features provided by the new kernel mount API interface about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/NYLYDK/

systemd v254 introduced a new reboot type: soft-reboot. It shortcuts the reboot process by not restarting the kernel, and instead shutting down userspace, followed by re-exec'ing systemd from the new rootfs, starting everything up again. Not only this allows to save time by virtue of doing less work, but it also allow select resources (File Descriptor Store) and select services that do not use the rootfs (Portable Services) to survive the reboot and continue uninterrupted. This talk will explore the details of this new feature, how it works, why it's useful, what are the shortcomings and how to make full use of it. In many environments where image-based Linux is used, service interruption intervals are key metrics that need to be minimized as much as possible. On a traditional package-based distributions, the rootfs can be updated piecemeal and userspace services can be restarted one by one - assuming a perfect running dependency tracking system and perfect reliability (need to restart D-Bus? Good luck!). On an image-based system this is obviously not possible, so a typical approach is relying on 'kexec', which loads a new kernel + initrd + rootfs, saving some time from a full reboot by avoiding giving back control to the firmware. But it turns out, it's not fast enough. systemd v254 introduced a new reboot type: soft-reboot. This follows in the kexec footsteps by shortcutting the reboot process, and brings it ever further: the kernel is not restarted at all, and instead userspace is shut down and then systemd is re-exec'ed from the new rootfs, starting up again. Not only this allows to save time by virtue of doing less work, but it also allow resources (File Descriptor Store) and select services that do not use the rootfs (Portable Services) to survive the reboot and continue uninterrupted. This talk will explore the details of this new feature, how it works, why it's useful, what are the shortcomings and how to make full use of it. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/XVV9QY/

Let's discuss about `bpfilter`, a userspace daemon that empowers services to create efficient packet-filtering BPF programs using a high-level representation of filtering rules. For a significant period, `bpfilter` wasn't more than an empty [usermode helper](https://cateee.net/lkddb/web-lkddb/STATIC_USERMODEHELPER.html) and an [abandoned patch series](https://lore.kernel.org/bpf/[email protected]). However, it has recently undergone active development as a userspace daemon, which can be found on GitHub at [https://github.com/facebook/bpfilter](https://github.com/facebook/bpfilter). This daemon now offers userspace services a swift and user-friendly interface to generate packet-filtering BPF programs dynamically. This discussion aims to provide further insights into `bpfilter`, including its current capabilities, performance, and ongoing development efforts. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/BKLNWP/

strace is a traditional userspace tracer utility for Linux, implemented using ptrace API. Despite of the abundance of various kernel tracing interfaces nowadays, there are certain classes of tasks that are still better served by strace. In this talk the maintainer of strace will provide examples of such tasks. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/GUVYJ7/

Stopping the old and starting a new service afresh -- that is what service restart is roughly about. We will look what it comprises in more detail from service manager perspective and also from the service's client end. Thus we will look at how FDSTORE API can be used to smooth service restart. Furthermore, we will review how unit instances may provide further distinction between the stopped and the restarted service. Finally, we go through options that the existing service have to adopt these methods. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/FYHCNJ/

Using an image-based OS brings advantages and challenges. One challenge is the customization of a read-only image with additional host-level software and configuration, and how to manage this customization through the lifetime of a machine. For deeper changes in /usr, users might build their own images instead of following the official image updates. For common scenarios, the vendor may choose to offer multiple image flavors. Simpler user customization can live outside of the read-only /usr, scattered as config files and binaries in /etc and /opt. Configuration management tools struggle with reliable (re)configuration because tracking filesystem state is hard. The systemd project now supports a mechanism for extension images. There are two types; system extensions create an overlay for /usr or /opt and configuration extensions create an overlay for /etc. Through the overlay, users can thus change the read-only /usr without building custom OS images. Vendors can also offer their supported flavors as extensions instead of different OS images, even as composable stack where the user can choose optional parts. Users can manage their configuration by replacing the extension images atomically. Since the images bundle all files, this prevents old files lingering around or a system in a half-finished state. The read-only extension images help with setting up attestation and integrity enforcement for their contents. For distributions providing prebuilt initrds (e.g., the Fedora mkosi-initrd proposal), extensions allow initrd customization provided by the distribution or user. The presentation will give an overview, share use cases and examples, and discuss future improvements for extension images. A recent addition to the systemd toolbox was systemd-sysext for system extensions through overlay images mounted on /usr. Even newer is systemd-confext for configuration extensions through overlay images mounted on /etc. The main use case for systemd-sysext is the customization or deployment of additional software on an image-based OS where /usr is read-only. The use of single images that contain all files allows to reliably manage the changes compared to unpacking files to the root filesystem. Optional dm-verity protection ensures the integrity of the extensions. A simple version matching scheme allows to either couple the extension to the OS version or not. The first case is useful for officially released OS extensions or dynamic linking, the second for static linking and only few assumptions about the host. For systemd-confext the use case is similar as with systemd-sysext but it focuses on configuration in /etc. Here again, the use of single image files makes configuration changes more reliable. Ideally the use of configuration images should allow to have /etc read-only at runtime, following the idea of immutable infra. However, not all software and workflows are prepared for that, and the goal is to introduce different modes for the overlay to, e.g., support ephemeral or persistent changes. Other plans are to set up the overlay mount from the initrd already to have all configuration in place as early as possible, and to improve the live reload behavior through atomic mount operations and system reload actions. The presentation will show how to use systemd-sysext/confext and share some examples from Flatcar Container Linux and an embedded Linux platform for both coupled and decoupled extensions. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/XLQNDJ/

With the introduction of "Forensic Container Checkpointing" in Kubernetes 1.25 it is possible to checkpoint containers. The ability to checkpoint containers opens up many new use cases. Containers can be migrated without loosing the state of the container, fast startup from existing checkpoints, using spot instances more effective. The primary use case, based on the title of the Kubernetes enhancement proposal, is the forensic analysis of the checkpointed containers. In this session I want to introduce the different possible use cases of "Forensic Container Checkpointing" with a focus on how to perform forensic analysis on the checkpointed containers. The presented use cases and especially the forensic analysis will be done as a live demo giving the audience a hands on experience. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/FZNLRT/

At Meta, we've been working to add encryption support to btrfs, with exciting implications for per-container security. Traditionally encryption has either dealt with whole disks, with LUKS, or with a few filesystems: ext4, f2fs, ubifs, and ceph, lacking in advanced volume management. Btrfs has several features these filesystems don't: deduplicating/reflinking identical data, subvolume/snapshot management, and integrated checksumming. These features allow giving containers their own encrypted subvolume with a key only loaded when the container is running, preventing container storage from being read while turned off, and making deletion of expired containers' storage secure. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ZJDHRA/

In this presentation, we introduce 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'll delve into Inspektor Gadget's automatic data enrichment process, transforming complex kernel information into high-level, understandable concepts tied to Kubernetes, container runtimes, systemd, etc. This feature bridges the knowledge gap between raw, low-level data and more interpretable information, improving the understanding of system behavior. We will illustrate how to use a simple configuration file to set up a data collection pipeline with Inspektor Gadget, resulting in a Prometheus endpoint or an exposed API. Throughout the talk, we'll demonstrate Inspektor Gadget's features, support across various environments, discuss its operational mechanics, and share insights into the future direction of the project. By presenting at ASG!, our aim is not just to inform the audience of Inspektor Gadget, but also to encourage feedback and stimulate discussions within the eBPF and Linux community. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ZSTFTF/

UKIs are a fundamental building block of modern measured and trusted boot chains. Let's have a look at what happened in the area and discuss recently added new concepts, such as "add-ons", new PE sections, build tools and more. about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/ZEVAWH/

A welcome session for All Systems Go! about this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/X89KG9/

A conversation about digital EU politics in the present and future A conversation about EU digital policy now and in the future. The event will be a structured AMA (ask me anything). So we need your questions! We will structure the questions to ensure a smooth conversation. Questions we touched on in conversation: - Can you briefly explain the difference between Europe and the EU? - Do you represent the "Danish people" or the whole EU? - What is your opinion about the EU "chat control"? What can we do to stop it? What are you going to do? - What is your personal utopia for Europe? What positive changes would you like to see in the next few years? "EU digital legislation in the 2020's: The Good, the Bad and the Ugly" https://media.ccc.de/v/bornhack2022-4200-eu-digital-legislation about this event: https://c3voc.de

Closing, thank yous, sponsors, what's next, anything else about this event: https://talks.nixcon.org/nixcon-2023/talk/NRSXHT/

microvm.nix builds NixOS for a few virtual machine managers in a few different use-cases Full virtualization suffers from overhead and performance degradation due to software emulation of real hardware. MicroVMs are optimized by replacing this emulation with interfaces that have been optimized for the virtual machine use-case: VirtIO. microvm.nix helps you building and running NixOS on different virtual machine managers. You can use it in different use-cases, for example as a more isolated alternative to nixos-container. about this event: https://talks.nixcon.org/nixcon-2023/talk/RNTYJF/

Nix is an amazing build tool not only for applications, but also for the infamous "yaml engineering". Join Volodymyr to learn about the journey of using nix along with argocd to deploy payloads into kubernetes. What you will learn: - Setting up nix to work with argocd - Deploying simple applications written purely in nix - Utilizing the public helm charts in nix, with custom configuration and resource overriding without the chart forking - Using nixpkgs' modules system for complicated muti-cluster deployments about this event: https://talks.nixcon.org/nixcon-2023/talk/CYEPCX/

I've been using a Librem 5 running NixOS for a few months now as my daily driver. Here are the challenges I've faced, what works and what doesn't. about this event: https://talks.nixcon.org/nixcon-2023/talk/Q3YYMR/

Tvix is a modern design and implementation of the Nix package manager (GPLv3). It brings a modular architecture in which components such as the build environment or package store are replaceable, which enables new use-cases and platforms. This talk will give a status update on the current state of the project, and an outlook on the roadmap. about this event: https://talks.nixcon.org/nixcon-2023/talk/Z897S3/

It's been twenty years since Nix was unleashed upon this world, and yet, the only real alternative is Guix‽ Well, not on my watch! I've been working on Zilch for a while now, and it's starting to be ready to be released to the wild. This talk will describe what this fresh new Nix-compatible alternative is, how it came into being, and what the wider Nix community could learn from it. about this event: https://talks.nixcon.org/nixcon-2023/talk/DDVFVZ/

Building every operating system starts from something. I'm not as hardcore as the stage0 project folks going from assembly to Guix, but a shorter path from a ~320 KB TinyCC binary to Nix to a proof-of-concept Linux distribution also proved to be a story worth telling. We'll begin our journey by executing a -nostdlib C program with TinyCC, compile our way out towards a libc and a shell, work through older compilers to modern compilers and build Nix. Then we'll walk the same path again once over, but this time, we'll use Nix. Finally, in a different flake, we'll reimplement some of the founding nixpkgs patterns, work our way from toolchain to Linux and arrive at a bootable .iso. Corners will be cut, hacks will run amock, Nix will be both praised and complained about, reproducibility will be earned hard, and some patches will get upstreamed. Links: https://github.com/ZilchOS/bootstrap-from-tcc, https://github.com/ZilchOS/core, http://bootstrappable.org about this event: https://talks.nixcon.org/nixcon-2023/talk/DDQRWQ/

. about this event: https://talks.nixcon.org/nixcon-2023/talk/DHXKNW/