Files
systemd/units
Christian Brauner 24548be0bf keyring-setup: add systemd-keyring-setup
The kernel has various keyrings that early userspace may choose to set
up. Right now it has the .fs-verity and .dm-verity keyrings and in the
next kernel it will also have a .bpf keyring.

All three keyrings accept X.509 certificates in DER form. The
.dm-verity and .bpf keyrings are inactive and restricted by default
unless the respective kernel command line options are passed that leave
them unrestricted. Both keyrings are ignored until they are restricted.
IOW, restricting them causes the kernel to use them for signature
verification.

The .fs-verity keyring has slightly different semantics. It is always
active and is taken into account as soon as it contains a key.

Add systemd-keyring-setup which provisions the keyrings based on the
VOA spec from the kernel-keyring role with the keyring as the context:

  .dm-verity -> kernel-keyring/dm-verity/
  .fs-verity -> kernel-keyring/fs-verity/
  .bpf       -> kernel-keyring/bpf/

Trust anchors are read from the trust-anchor-kernel-keyring/
counterpart. Note that the "trust-anchor-*" prefix is mandated by the
spec.

The systemd-keyring-setup binary reads
<os>/kernel-keyring/<context>/x509/*-certificate.pem and the
trust-anchor-kernel-keyring/ counterpart from all VOA load paths and
enrolls the certificates into the corresponding keyring. Afterwards it
restricts the keyring to certificates signed by an enrolled key and
drops the SetAttr permission. Hence, neither the restriction nor the
mask can be changed anymore.

The binary may run in the initrd and on the host. A second run detects
a sealed keyring by its permission mask, skips certificates that are
enrolled already and enrolls certificates that are signed by an already
enrolled key.

Any unprovisioned keyrings are sealed at the end of a run even when
empty. Failing to enroll a certificate still causes the keyring to be
sealed. We can make this more flexible in the future but I don't think
leaving a keyring open just because enrolling a key failed makes sense.

Note that a file holding more than one certificate is refused.

Note that on a second call to add_key() for a certificate with the same
subject and key the kernel silently replaces the first. We can detect
this by reading the keyring's members before and after enrollment.

The binary exits with EX_DATAERR for input that can be fixed and
EXIT_FAILURE for kernel refusals. --dry-run only shows what would be
enrolled, optionally as JSON. The service isn't enabled by default and
the tool is marked experimental for now.

systemd-keyring-setup is written in Rust on top of the systemd_shared
crate. The VOA lookup, the keyring and X.509 helpers and everything
else it uses stay C in libsystemd-shared. All lookups are anchored at
the root directory which is opened once. The program, its unit and its
man page are only built with Rust support.

Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-10-26 18:55:53 +01:00
..
2026-10-25 09:34:00 +09:00
2022-07-20 13:15:37 +09:00
2024-03-16 05:31:44 +09:00
2024-03-16 05:31:44 +09:00