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

But only to some point. First of all "reinstalling your Linux" is not precisely a trivial operation, and secondly, in today's world it's actually not really going to suffice in many ways. That's because it's not sufficient to erase your HDD an reinitialize it. There's more state to reset. One of them in particular is the TPM: local key material is derived from or protected by a "seed" key stored on the TPM.

… (i.e. lots of similar systems running the same OS image), but equally on "pet" style installs (i.e. your personal device).

Or to turn this around, a system that doesn't come with a clean, well defined mechanism to reset it fully, erase all unauthenticated data and return it to a vendor image without any local modifications, is highly problematic I believe.

Now you might say: "I can always reinstall my Linux" and start from scratch. And to some point you are right even.

And once the system comes back again the system is fully reset.

This currently does not cover EFI var NVRAM reset natively, but there's a clean plugin interface now to do that eventually (two actually: one place where you can plug in such code *before* we reboot, and one place *after* we reboot). [I'd expect that in one of the next releases we'll add another plugin for this, that erases certain EFI vars in NVRAM].

With v258 we considerably extended this work.There's now a well defined way to extend the factory reset logic so that other subsystems can be reset too. And we do ship one plugin for that (which is enabled by default), that requests a TPM reset from the firmware.

If your OS is properly set up for that you can now issue "systemctl start factory-reset.target". This will initiate a reboot, but a special one, where first the firmware will reset the TPM, and then the OS will reset its own state.

If you do not invalidate the old seed key and generate a new one, then all secrets associated with the compromised install (and thus tainted) will remain valid.

And there's more: there are various bits stored in EFI vars NVRAM that need to be reset too (shim keys for example).

systemd for a longer time has had really nice support for resetting your HDD (i.e. securely erase partitions, via the systemd-repart FactoryReset= knob) if a factory reset is requested.

There's also now a Varlink based API to query the current factory reset state (i.e. is a factory reset pending for the next reboot, or are we currently executing one for the current boot, or did we already finish one for the current boot, or is none pending nor executing).

If you want to learn more about the factory reset concepts in systemd, there is a new document for this:

https://github.com/systemd/systemd/blob/main/docs/FACTORY_RESET.md

In v258 we updated this area substantially. There's now a Varlink IPC call to subscribe to all DNS configuration changes (io.systemd.Resolve.Monitor.SubscribeDNSConfiguration() on /run/systemd/resolve/io.systemd.Resolve.Monitor).

If you issue this you'll get a stream of updates of the DNS configuration as they happen.

Why is this useful? This is used by systemd-networkd-wait-online's new --dns switch. If specified it will not only wait until a suitable network interface with…

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

One of systemd-resolved's fundamental jobs is to maintain per-interface and global DNS configuration (as well as per-delegate configuration, as described earlier in this series). We always provided D-Bus APIs to query the current state of this, and "resolvectl" to a large degree is just a wrapper around that.

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

The concept of system credentials has existed since a while in systemd. It allows parameterizing the system (and the services running on it) in a secure and hierarchical way. You can pass them into containers and into VMs, for example via SMBIOS Type #11 vendor strings. While the transport is low-level and firmware compatible, they can reasonably only be consumed in userspace.

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

Most Linux folks probably spend much of their day in their terminal emulator. Such emulators ultimately reimplement in software what dedicated hardware terminals did in the 1980's and before. While the protocol terminals speak didn't change much in its most basic concepts, various extensions have been added over the years to integrate terminal emulators better with the windowing…

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

On modern Linux systems the persistent hostname is configured in /etc/hostname. Linux people treating their devices like pets tend to come up with nice, imaginative names for their hosts.

But this doesn't scale: if you have a large number of devices to manage (i.e. "cattle") then you typically want something more automatic: the hostnames used should follow some specific pattern, …

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`)