Christian Brauner

On most POSIX systems including Linux file ownership can only be changed globally, i.e. for all users through the chown*() syscall family. In this talk we will introduce idmapped mounts. Idmapped mounts allow to change the ownership of files under the mounts they appear in.

File ownership is a global property on most systems that have a uid and gid concept. On POSIXy systems the chown*() syscall family allows to change the owner of a file or directory. If the ownership of a file is changed it will be changed for each user on the systems equally. But various use-cases exist where this can be problematic: - Portable home directories that are used on different computers where the user is assigned a different uid and gid. - Filesystems that allow to merge or unionize multiple filesystems are often shared between different users. - On Linux user namespaces used in containers also affect file ownership. - Chowning files on really large filesystems is costly. Idmapped mounts solve these problems and others by allow bind-mounts to specify idmappings allowing to change file ownership on a per-mount point basis. In this talk we will take a close look technical at the idmapped mount patchset, the use-cases it is intended to solve, and we will demo it's capabilities.

Recently the kernel landed seccomp support for SECCOMPRETUSER_NOTIF which enables a process (supervisee) to retrieve a fd for its seccomp filter. This fd can then be handed to another (usually more privileged) process (supervisor). The supervisor will then be able to receive seccomp messages about the syscalls having been performed by the supervisee.

We have integrated this feature into userspace and currently make heavy use of this to intercept mknod(), mount(), and other syscalls in user namespaces aka in containers. For example, if the mknod() syscall matches a device in a pre-determined whitelist the privileged supervisor will perform the mknod syscall in lieu of the unprivileged supervisee and report back to the supervisee on the success or failure of its attempt. If the syscall does not match a device in a whitelist we simply report an error.

This talk is going to show how this works and what limitations we run into and what future improvements we plan on doing in the kernel.

Traditionally processes are identified by process identifiers aka PIDs. These are globally unique identifiers. As such users do not hold a stable reference on the process they identify. Because of that PIDs will be recycled by the kernel. This means a PID might refer to a different process than what a user thought it did. As such PIDs are inherently racy, e.g. a process might end up sending a signal to PID which referes to a process it didn't itend to signal. To solve this long-standing problem Jann Horn and I have introduced the concept of file descriptors for processes aka pidfds into the kernel. As things stand kernel 5.2. might gain the ability to refer to processes via file descriptors, making it possible for a process to get a stable and private reference on a process. Even if the PID is recycled the pidfd will refer to the original process. In this talk I will look at the history (in other systems) and the general idea of using pidfds, the work we had to do, and what we have planned for the future. #### Über mich Christian Brauner is a kernel engineer and core developer and maintainer of the LXD and LXC projects. He works mostly upstream on the Linux Kernel and lower-level problems. He is strongly committed to working in the open, and a strong proponent of Free Software. #### Vorwissen Some knowledge around process management and process identifiers (PIDs) and file descriptors (fds) would be nice. But we can work around it. :)

In this talk we will focus on container related kernel features. We will take an in-depth, technical look at what features have been worked on, are currently worked, or are planned.

Containers have become ubiquitous. Nowadays, the computing landscape is mostly concerned with a higher-level view on the functionality and features of containers (e.g. orchestration). In this talk we will take a step back and focus on the low-level aspects that make containers possible. Specifically, we will look at kernel features that have been implemented in the last year(s), features that are currently being worked on and features that are planned in the future. We will try to take a closer technical look and not shy away from analysing code and patchsets where needed. The goal of the talk is to inform users about the kernel development status but also to raise awareness that all the shiny glitter takes a lot of difficult technical arguments and patches that are not just "boring plumbing" but actually are pretty exciting.

On non-embedded systems device management in Linux is a task split between kernelspace and userspace. Since the implementation of the devtmpfs pseudo filesystem the kernel is solely responsible for creating device nodes while udev in userspace is mainly responsible for consistent device naming and permissions. The devtmpfs filesystem however is not namespace aware. As such devices always belong to the initial user namespace. In times of SR-IOV enabled devices it is possible and needed to hand off devices to non-initial user namespaces. The last couple of months I've been working on making device management in the Kernel namespace aware. With recent patchsets of mine we have now reached that goal. As such userspace can now tie devices to a specific user namespace. This talk aims to do a couple of things. First, to give a more in-depth explanation of device management in Linux. Second, to explain the concept of namespace aware device management. Third, to explain the patchsets that were needed to make device management namespace aware. And last, to argue for a proper in-kernel solution by namespacing devtmpfs itself in the future. ### Vorwissen I'll explain anything that's missing even if it means we can't get through everything. I can't fit all links that are helpful down below so I'll add a couple of them here: - devtmpfs: See [https://lwn.net/Articles/331818/](https://lwn.net/Articles/331818/) for an overview and [https://lwn.net/Articles/330985/](https://lwn.net/Articles/330985/) for the actual patchset - ueventd (Android's device manager): [https://android.googlesource.com/platform/system/core/+/master/init/ueventd.cpp](https://android.googlesource.com/platform/system/core/+/master/init/ueventd.cpp) - systemd-udevd: [https://www.freedesktop.org/software/systemd/man/udev.html](https://www.freedesktop.org/software/systemd/man/udev.html) - eudev (standalone fork of systemd-udevd): [https://github.com/gentoo/eudev](https://github.com/gentoo/eudev) ### Über mich Christian Brauner is a core developer and maintainer of the LXD, LXC, and glibc projects. He works upstream for Canonical as part of the Ubuntu Server team on the Linux Kernel and lower-level problems. He's been active in the open source community for a long time and is a frequent speaker at various large Linux events; he is also strongly committed to working in the open, and a strong proponent of Free Software.

LXD has supported container migration between hosts for a long time. Recently we have not just implemented optimized transfers of container storage for non-live migration and live migration but also optimized transfers of the container's memory state for the live migration case. This talk will give an overview how live and non-live migration works and what was done to tweak performance.

The LXD daemon supports container migration. It supports non-live migration in which case the container's filesystem will be transferred in an optimized way. In addition to non-live migration LXD has been supporting live migration of containers. This means that volatile process information associated with a given container is migrated in addition to the filesystem. Part of this volatile information is the container's memory state at a given point in time. A container can either be live-migrated by dumping the memory state to disk once and transferring it or by performing a series of memory dumps that aim to minimize the delta between each consecutive dump in order to guarantee an optimized and more reliable way of transferring the container's memory state. This is achieved by making use of CRIU's pre-dump features. This talk will outline the steps that were taken to optimize filesystem and memory transfer when migrating container's between hosts.

Other people: Adrian Reber