Notices by Lennart Poettering (pid_eins@mastodon.social)

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!

@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? ;-)