From 79b69ae9beee385457dabe63d22b6bfa0a9a602e Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Tue, 27 Oct 2026 10:40:21 +0000 Subject: [PATCH] man: rearrange and slightly expand sd-keyring-setup note Move kexec paragraph down to the bottom of the manpage, to the existing 'Security Considerations' section since it's a better fit, and add a sentence to clarify the implications, to be extra clear and most importantly to avoid bots reporting bogus security issues. Follow-up for fb6167ca1fbd31199d70ba5e64ca060f8e646d5e --- man/systemd-keyring-setup.service.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/man/systemd-keyring-setup.service.xml b/man/systemd-keyring-setup.service.xml index ee061d39674..e8f0f88b506 100644 --- a/man/systemd-keyring-setup.service.xml +++ b/man/systemd-keyring-setup.service.xml @@ -94,8 +94,6 @@ were already in the keyring before the service ran are sealed in as well, and a warning is logged about them. - Note that kexec will unseal and empty the keyrings. - The service runs both in the initrd and on the host. Usually, the keyrings are provisioned in the initrd, since the root file system might itself be a dm-verity volume that is verified with one of the enrolled keys. When the service runs again on the host, the keyrings have been sealed already. In this case, @@ -281,6 +279,10 @@ dm_verity.keyring_unsealed=1 is set, the new keyring may then be provisioned with arbitrary keys again. systemd-keyring-setup logs a warning if a keyring belongs to a loadable kernel module. For high-security setups, dm-verity should be built into the kernel. + + Note that kexec will unseal and empty the keyrings. If enabled and allowed, the caller may use it + to load their own certificates into the chain of trust, so this is out of scope for this component + and needs to be handled by the system integrators with an appropriate security policy.