Notices by Lennart Poettering (pid_eins@mastodon.social)

And then there are three other talks, in the aforementioned Image-based Linux & Boot Integrity devroom (about systemd & TPMs), in the bootloader devrom (about supercharged UKIs) and in the identity management devroom (about systemd' userdb API).

And then your's truly will give four talks, at various different places. First of all I have a keynote:

https://fosdem.org/2025/schedule/event/fosdem-2025-6648-14-years-of-systemd/

And unlike some well-known billionaire I am not going to chicken out of my mine. Ha!

PSA: There's going to be a lot of systemd related stuff going on at FOSDEM this weekend. Many folks from the systemd camp and adjacent will be hanging out at the Image-Based Linux & Boot Integrity devroom:

https://fosdem.org/2025/schedule/track/image-based-linux/

And of course, outside of the image-based linux track, and other than my own talks there's some more systemd adjacent talks in other tracks, for example, Ani Sinha talks about bring-your-own-firmware UKIs, in confidential computing cloud stuff, booting from mkosi initrd in the network in the distributions devroom (by Antonio Feijoo), running podman containers as systemd services (by Axel Stefanini), and probably some more I missed.

See you all in Brussels!

@michelin yeah, all the money in the world, and yet he's chickening out when seeing just a tiny bit of opposition...

@jarkko It's a long text, but the person writing this is basically saying that a TPM2 policy for a disk that only locks to PCR 7 or not even that is not secure? I mean, no shit sherlock, of course it doesn't. If you policy doesn't lock to anything then it doesn't lock to anything...

A full boot chain that gets things right would include at least a UKI with a signed PCR policy + a dynamic systemd-pcrlock policy. The combination should be reasonably secure, I'd claim, but if you have neither…

@jarkko … then you have only a very weak model, probably to the point it's not worth it.

What matters is that distributions actually start deploying UKIs like this, and enable systemd-pcrlock by default. This is not trivial, but some distros are further ahead there then others.

@axboe @osandov but the folks who commented there are marked "senior" in their UI. Hence, they are the true *pros*, and you, you are are just ... *somebody*.

@Foxboron christ. I guess that means that I am not the only asshole doing a keynote there, eh? ;-)

…the AF_VSOCK "CID" (which is like an IP address, i.e. an identifier for the local VM) you can specify a friendly machine name, if the VM in question is registered with systemd-machined. systemd-vmspawn sets things up that way out of the box, of course. That means, with current off-the-shelf systemd inside a VM and on the host you can now just do "ssh machine/foobar" to connect to a local VM called "foobar", via AF_VSOCK, i.e. independently of any fragile network.

3️⃣7️⃣ Here's the 37th post highlighting key new features of the current v257 release of systemd. #systemd257

In systemd v256 we added a small tool "systemd-ssh-proxy" whose job is to allow connecting to local VMs with ssh via the AF_VSOCK protocol (as opposed to AF_INET/AF_INET6). It acts as host-side counterpart to the guest-side systemd-ssh-generator that automatically binds sshd to AF_VSOCK.

In systemd v257 the functionality has been updated so that instead of specifying…

And that's it! After 37 installments I think I covered pretty much all the bigger things in the NEWS file with a story.

Of course, there's a lot more in this release. For the full list, consult our NEWS file:

https://github.com/systemd/systemd/blob/70bae7648f2c18010187c9cf20093155eaa26029/NEWS

Stay tuned so that you won't miss out on the #systemd258 series when the time comes for the next release!

This is extremely handy, since it "just works" here. In fact, I switched over to this for my private VM needs entirely now.

(In related news, systemd-ssh-proxy now supports the AF_VSOCK "MUX" protocol too. This means it's now compatible not only with AF_VSOCK how it's implemented by qemu, but also with the implementations in Firecracker/CloudHypervisor)

Here's a blog story with links and very brief summaries of all those #systemd257 stories on Mastodon:

https://0pointer.net/blog/announcing-systemd-v257.html

Enjoy! And stay tuned for #systemd258!

All in all I would say systems became a lot more debuggable out of the box this way, which is not just good for quickly tracking down issues in production environments, but I also see as a relevant in context of the open source philosophy: since the whole OS is typically open source, it also means coredumps are comprehensively useful, since you can always cross-link the stackframes to the sources: the pathway from execution to the sources behind it is now nicely paved.

…are in a pretty good position: we use libdw to generate the stack trace, running inside a local sandbox (since generating stacktraces means analyzing frequently corrupted, possibly differently privileged, complex data, which is hence security sensitive par excellence), and since the relevant distributions now ship minidebuginfo packages and are built with frame pointers enabled the default stacktraces you get this way are typically quite useful – without having to bother with gdb or so.

3️⃣2️⃣ Here's the 32nd post highlighting key new features of the current v257 release of systemd. #systemd257

One of the features we added on early to systemd was coredump processing. We wanted that crashing processes on one hand could be treated very much like any loggable event, and on the other hand be truly and immediately useful, i.e. the log messages generated should already carry a fully symbolized backtrace.

The path towards that goal was rocky, but today I think we…

…the container is just like handling on the host, and the processing of the dump data is done within the immediate sandbox and context of the code that owns it. Great!

Except of course that this is only a full solution if the container actually is able to do all that, i.e. is complete enough to actually do this kind of processing on its own. Effectively this means that the CoredumpReceive= logic only really works for "full-OS" containers, i.e. containers how they are typically run…

It's a boolean option: if enabled the coredump processing on the host would forward the coredumps to the unit's code. The idea is that a container manager enables this on the container's unit, and this magically ensures that coredumps that happen inside the container are delivered to the container itself, and are then processed inside of it, with the container's own coredumping logic.

Security-wise this is really nice behaviour I think: to a large degree coredump handling inside…

…logged events it all stopped on the container boundary: only with luck you'd get a proper backtrace, but you usually didn't because the coredump processor on the host couldn't deal with the different compiler/debug situation inside the container. Given that containers are mildly successful these days this of course is a big problem.

Back in v255 we added a new unit file setting CoredumpReceive= to unit files (services and scopes in particular), to address this issue.