…images that make use of fs-verity rather than dm-verity. Or in other words: every file placed in generated images can be locked down with fs-verity, and made immutable. The CopyFiles= setting in repart.d/ drop-ins gained the new "fsverity=" option string, which may be used to enable this logic.

This is useful for building images for consumption by "composefs", usually found in ostree deployments.

…there are security models that differ from this, and focus on the protection of the files themselves only, not so much the data structures to access them. While the previously described Verity logic focuses on the block device layer, and is implemented in the kernel subsystem "dm-verity", the latter security model can be implemented via the "fs-verity" subsystem of the kernel, which is available for various file systems, including ext4.

With v258 systemd-repart also supports generating…

This kind of protection – so far – focused on block-level protection: not only the files are protected, but their whole arrangement in the data structures of the file system is too. Thus an fs driver can be reasonably sure that if a file system comes from a properly signed Verity-protected image it's structure is safe to access.

While I strongly believe in a security model where trust into file system images must be established before accessing it – in a way like the one describe above –…

Note that this line is only shown if all of the below apply:

* the system runs in a VM

* AF_VSOCK is available

* sshd is installed

* And sshd actually has been successfully bound to a AF_VSOCK socket.

…a drop-in file /run/issue.d/50-ssh-vsock.issue that contains one brief sentence with the command line to use to connect to the VM, including the CID.

The files in /run/issue.d/*.issue are shown by the "login" process that is responsibly on Linux to show the login prompt. Or in other words: when you get the console login prompt on a VM system you'll now also get a suggestion how to log into it via ssh-over-AF_VSOCK as alternative means.

It's also part of the "hostnamectl" status output that shows basic information about the host. But you'll only get to that once you logged in.

Wouldn't it be great if the system would actually show it prominently on the console once it booted up, so that you can immediately see it when the system is ready to take your connections?

Precisely that has been implemented in v258. The .socket units that bind the AF_VSOCK will now call a tiny new tool systemd-ssh-issue that will generate…