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

@oclsc uh? /etc/nologin is long obsolete. it's located in /etc/ which we have to assume to be r/o in the general case, in particular in early-boot and late-boot, where the files is touched. It was moved to /run/nologin more than a decade ago, to clean this up, since it's volatile, and modified on every single boot+shutdown. Making changes to /etc/ for a purely *runtime* param was just super broken, and that's something we fixed. So no, this is not chaos, there are reasons. Thank you very much.

…of processes, which creates a number of security and robustness issues. (These issues are not just theoretic, the PID space is so small that PID recycling is trivially easy to trigger and even happens by accident quite often).

New Linux kernels provide a way out: there are now "pidfds", i.e. fds that reference a specific processes. Which is a stable handle to processes, even beyond their lifetime. And their inode numbers are 64bit integers that are never recycled during…

The former is useful in auxiliary processes associated with a service (for example ExecStartPost=, ExecStop= or so) for interacting with the main process of the service, for example to send a UNIX signal to it. The latter may be useful for service code to auto-detect if it is invoked by a service manager (in which case getppid() must match $MANAGERPID) or from a shell.

But we live in 2025, and POSIX PIDs are quite broken: they are recycled too frequently to be useful as stable identifiers…

4️⃣2️⃣ Here's the 42nd post highlighting key new features of the upcoming v258 release of systemd. #systemd258

Part of the protocol spoken between service processes and the service manager (if it is systemd, that is) are a number of environment variables. Specifically, $MAINPID and $MANAGERPID are two variables that have been part of the protocol for a long time: they contain the PID numbers of the main service process and of the service manager itself.

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

systemd tries to bridge the gap between being modular and flexibily supporting a wide range of systems and devices on one hand, and being somewhat quick and efficient to boot up on the other. These two goals are sometimes opposing forces: on many systems step X has to be done on boot, but each such step X costs dearly on other systems where X is not needed.

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

In various stateless situations it makes sense to boot directly into a root file system that is downloaded as part of the boot process and placed into system RAM. With v258 there's now native support for this: a new rd.systemd.pull= kernel command line option may be used to download DDIs or tarballs into a tmpfs, optionally authenticate them, and then boot into them.

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

In v256 we added "systemd-ssh-generator", which – among other things – would bind sshd to an AF_VSOCK socket if that is supported on the system, i.e. if booted inside a VMM that supports AF_VSOCK communication. It greatly simplifies talking to a VM from the host, in environments that support this.

Except of course, it's not quite as easy as it might appear conceptually:

@agowa338 @siosm not sure what you are going on about, but the way the trust chain concept works on modern computers is that you boot up in a trusted state, and then chain everything else from there. Hence of course, you reboot to reset the state, to get your trust chain into a clean state again?

Note that all of systemd's factory reset work actually runs from the initrd, i.e. under the assumption of an UKI world in a fully vendor signed part of the OS with only minimal input from elsewhere.

@siosm you definitely need to reboot, to get back into an unbroken chain of trust. Now you have two ways to ensure this works. First of all you physically request the reset early during boot. That's why we have this in the boot menu. Or you ask for the reset from the compromised running system, and then use some form of attestation to validate that the reboot was genuine. The latter is stuff bigger deployments (i.e. companies which actually do attestation) can do, …

@agowa338 @siosm sure, if you can afford to dump all hw on the trash and never use them again, if you have the suspicion that they got compromised, knock yourself out. Not cool for the environment, kinda wasteful, but whatever.

I am pretty sure most people outside your bubble probably prefer a reasonable mechanism to maybe not waste all those resources, and get a clear and reasonably secure way to get the systems back to work.

@agowa338 @siosm

also, it's actually mostly fine to boot from a compromised disk as long as every resource involved is properly authenticated. Of course, the less you boot the better, but again when resetting the disks like this we do this from the initrd, i.e. from the signed, vendor-supplied UKI in a short-lived environment, not from the rootfs that might be user (and thus attacker) controlled.

But I think ultimately we can just agree to disagree on the security model, no?

@agowa338 @siosm

we are dumping the *state* on the trash. But a signed UKI isn't precisely "state". It's firmware-authenticated immutable vendor code.

But dunno, I think we should end this here. You have your security model, I have mine, let's just agree to disagree on it.

@agowa338 @bluca @siosm you can store the UKI signing key on any pkcs11 device btw, i.e. a yubikey if you like. An attacker who takes over your system shouldn't be able to get to that, if you lock it with pin + fingerprint.

@agowa338 @siosm sure if you make your UKI signing keys accessible to an attacker then of course there's no way to recover. Maybe don't do that then...

@agowa338 @siosm if you compile your own kernels you are your own OS vendor. In that case you better take care of your signing keys.

But this is not how most Linux distros or big installs are set up: they run kernels put together and signed on build systems, and those are distinct from the systems they are run on, and the signing keys are not available there.

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

I believe a fundamental aspect of OS security must be a secure way to return the OS into a well-defined, secure state if a compromise has been identified.

Fending of an attacker is one thing, accepting that it might happen anyway and that you can recover from that in a reasonable way is another. And that's the case not only if you think about "cattle" style installs…

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.