Christian Brauner

Very excited to be founding @amutable.com with @pid1.bsky.social and @cbrauner.bsky.social. We are joined by one of the strongest Linux teams I could imagine building important foundational technologies that enable whole new capabilities built on trust and integrity.

Ringing in 2026, I'm thrilled to join @amutable.com with @cbrauner.bsky.social, @chrskhl.net, and @pid1.bsky.social — alongside a wildly talented founding engineering team — to redefine what we expect for infrastructure integrity, declarative systems, compliance, and trust.

Amutable Amutable: A New Secure Foundation

Today I'm super excited to announce Amutable, our new company together with @pid1.bsky.social and @chrskhl.net .
We have an amazing founding team. I'm very happy they are on board for the ride. I can't wait to show everyone what we're building. Made with ❤️ in Berlin.

amutable.com/blog/introdu...

Amutable Amutable: A New Secure Foundation

Today we announce Amutable and our mission to deliver determinism and verifiable integrity to Linux systems.

Amutable is founded in Berlin by @chrskhl.net , @cbrauner.bsky.social and @pid1.bsky.social.

Read the announcement: amutable.com/blog/introdu...

YouTube video by Seppe Nihilist Penguin (Werner Herzog)

www.youtube.com/watch?v=mnTU...

A reminder that the All Systems Go! 2025 CFP closes on June 13th. Submit your talk about foundational user-space Linux technologies before the deadline to be considered.
👉 cfp.all-systems-go.io/all-systems-...

I feel like #Android would be a prime candidate to rely on SO_PEERPIDFD in their bluetooth stack. And if they don't, they probably should.

6/n

And even if the current crashing thread isn't the actual thread-group leader we know that the thread-group leader cannot be reaped until all of its subthreads have exited.

5/n

We're installing a pidfd for the thread-group leader even if a subthread is calling do_coredump(). We know that task linkage hasn't been removed yet.

4/n

Since usermode helpers are either children of the system_unbound_wq
workqueue or kthreadd we know that the file descriptor table is empty and can thus always use three as the file descriptor number.

3/n

When the usermode helper process is forked we install a pidfd file descriptor three into the usermode helper's file descriptor table so it's available to the exec'd program.

2/n

There are tricky race-windows that cannot be easily closed by userspace. There's various ways like looking at the start time of a process to make sure that the usermode helper process is started
after the crashing process but it's all very very brittle and fraught with peril.

1/n

Oh yeah, I already mentioned this a while ago but I also added support for pidfds in Linux coredumps.

/proc/sys/kernel/core_pattern has been extended so userspace can instruct the kernel to install a pidfd for the
crashing process into the usermode helper process, e.g., systemd-coredump.

(1) Are developers aware that Bluetooth sockets even support SO_PEERPIDFD?
(2) Is this useful for Bluetooth user space implementations?/Is this already used?
(3) Is it useful to also enable SO_PEERPIDFD for reaped peers for Bluetooth sockets?

The fun part is that Alex reminded me that Bluetooth sockets support at least SO_PEERPIDFD. I had forgotten about this and had blocked adding SCM_PIDFD support for them.

They don't yet support reaped SO_PEERPIDFD but they could be made to do so. I wonder mainly three things:

So all we really needed to do is register the peer in pidfs (the FS pidfds are based on for a while now). By doing this we're guaranteed that when the peer task gets reaped exit information will be available and we can safely allocate pidfds later on.

The advantage of the peer credential concept is of course that we stash the required reference (struct pid) at the time when the peer is still alive.

So we already have a stable in-kernel handle.

Ever since v6.15 it's possible to retrieve the exit status and cgroup ID from the pidfd via the PIDFD_INFO_EXIT flag of the PIDFD_GET_INFO ioctl() after the process has been reaped.

So with this it becomes even more useful to hand out pidfds for already reaped peer processes.

It's used by dbus-broker, polkit and systemd to guard against pid recycling and related issues.

So far it wasn't possible to get a pidfd if the peer process was already reaped. But there wasn't anything technically wrong with enabling this.

So a while ago we did pidfds for AF_UNIX sockets. Alexandr Mikahlitsyn did all of the heavy lifting. Specifically we added SO_PEERPIDFD and SCM_PIDFD. They are analogues to SCM_PEERCRED and SCM_CREDENTIALS.

Any process that doesn't have that {g,u}id but is still privileged otherwise will write to disk as the squashed {g,u}id. I just finished a draft and selftests that miraculously work.

Picked back up the work for VFS {g,u}id squashing. IOW, mapping all {g,u}ids down to a single {g,u}id.

web.git.kernel.org/pub/scm/linu...

libmount statmount support by karelzak · Pull Request #3092 · util-linux/util-linux Plan: use statmount() in libmnt_fs fill libmnt_table by listmount() on-demand read nodes from kernel by listmount() in mnt_table_next_fs() loops (mnt_table_next_lsmnt() as backend) allocate/sh...

util-linux has merged support for statmount() and listmount() to list mounts:
github.com/util-linux/u...

This should be a nice performance improvement.

See brauner.io/2024/12/16/l... for some details on listmount() and statmount().

#linux #kernel

FOSDEM 2025 - Containers

I'm organizing the #containers and #kernel devrooms at FOSDEM 2025 with the usual suspects.

containers: fosdem.org/2025/schedul...

kernel: fosdem.org/2025/schedul...

See you in Brussels!

I've written a post that shows how to list all mounts in all mount namespaces (all mounts on the system) using new apis we added to the #vfs last year.

brauner.io/2024/12/16/l...

#kernel #linux #vfs