Notices by Lennart Poettering (pid_eins@mastodon.social), page 2

6️⃣ Here's the 6th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

The concept of /tmp/ has been a constant source of local security vulnerabilities, mostly in form of a DoS: because /tmp/ is a shared namespace and less than perfect programs create files under guessable names there, which evil programs can then use to DoS them.

This has been like this time began and /tmp/ was invented.

…and all log messages queued at that point are fully processed and shown. And only once that part is complete, systemctl start -v may exit.

And the last part is the nasty bit: ensuring that all log messages enqueued at the moment the start operation completed are fully processed before we stop the log output. That's because journald takes log stream from a multitude of sources: classic syslog AF_UNIX, modern systemd AF_UNIX, stdout/stderr stream sockets, kernel kmsg and more.

Thus you might ask: why did it take so long to actually implement this? Well, simply because it's really hard to to implement, much harder than it might sound on the surface at first:

in order to make the logic work correctly we need to ensure two things: first, the live log output must be fully established by the time the start operation is enqueued. That's relatively easy to make sure. But the other thing is that we must continue the log output until the the start operation completed…

…is check the logs for the unit, i.e. run "journalctl -u …" on the unit.

With v258 there's now a combined way to do this. If you add the -v switch to your "systemctl start" invocation, "verbose" mode will be invoked, which means the logs will displayed "live" covering the time span when the start operation is started until the start operation completed.

This has been a much requested feature – I figure some of you probably even looked for this feature personally already.

It's that time again! The systemd v258 release is coming closer. Let's restart the "what's new" series of posts for this iteration! Hence:

1️⃣ Here's the 1st post highlighting key new features of the upcoming v258 release of systemd. #systemd258

As most of you probably know "systemctl start" is how you manually start a systemd unit. Starting a unit can fail, and systemd tracks that for you and tells you this. When you encounter such a failure the next thing you'd typically do…

Then, to make this nicer, it makes sense to allow deriving the URL to download the rootfs image from directly from the UEFI HTTP boot URL. Or in other words: if you point your UEFI to boot a UKI from some URL (i.e. http://example.com/somedir/myimage.efi), then that UKI's initrd is smart enough to derive from that same URL a different URL for the rootfs (by replacing the final component, so that it becomes http://example.com/somedir/myimage.raw.xz).

download the root disk image itself with this. There were a bunch of missing bits to make this nice though:

First of all, for raw disk images we need to attach them to a loopback block device, to make them mountable. Easy-peasy, systemd-dissect --attach already delivers that.

Then, for tar disk images we need to bind mount the downloaded and unpacked image to /sysroot/ (which is where the rootfs goes before we transition into it).

Fun little thing I have been working on: teach systemd to boot directly into a disk image downloaded via HTTP within the initrd.

In v257 systemd learnt the ability to download disk images at boot via systemd-import-generator, both DDIs and tarballs, and place them in /var/lib/machines/, /var/lib/portables/, /var/lib/confexts, /var/lib/extensions/. The goal was to provide a way to provision any of these resources automatically at boot. But now that we have this, we can take it a step further:

Sounds simple? That's because it is.

(Well of course, you wonder where the magic sauce is. It's here: you need to build your UKIs a certain way: i.e. add to the kernel cmdline: `rd.systemd.pull=verify=no,machine,blockdev,bootorigin,raw:root:image.raw rootflags=x-systemd.device-timeout=infinity ip=any`)

3. You simply reboot that target machine. It will now fetch the UKI kernel, which then fetches the root disk image. And everytime you reboot this happens again. The target's machine#s local disks are unnaffected.

4. …

5. Profit!!

It's mostly to tighten my test loop a bit, for physical devices. So here's what this entails:

1. You build your image with mkosi one your development machine, and ask it to serve your image as HTTP. In other words: `mkosi -f serve`.

2. You boot into the target machine once, and register an EFI variable that enables HTTP boot from your development machine. Simply do `kernel-bootcfg --add-uri=http://192.168.47.11:8081/image.efi --title=testloop --boot-order=0`, using @kraxel's wonderful tool.

Net result of this: I can now point my UEFI to a single URL where it will load the UKI from. A few seconds later the initrd will pick up the rootfs from the same source, and boot it up. Magic!

Why all this though?

and even one more comment:

next steps: instead of downloading root fs via http, access it via nvme-over-tcp.

Benefit: better performance (no ahead of time download, but download as needed), and even better: persistency!

oh, and one more comment: this will only work on systems that are relatively high on the systemd adoption scale: you definitely need a systemd-based initrd for this. For deriving the rootfs URL from the UEFI network boot URL you need a systemd-stub based UKI.

WIP PR for all of this is here:

https://github.com/systemd/systemd/pull/36314

So, two take-aways here:

1. Really nice test loop now for testing immutable, modern OSes on physical devices, with onboard tooling

2. Yeah, you can frickin' boot into a damn tarball now, with just an UKI.

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!