On Mon, 2024-06-17 at 23:00 +0100, luca.boccassi@xxxxxxxxx wrote: > From: Luca Boccassi <bluca@xxxxxxxxxx> > > Add a new configuration > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING > that enables verifying dm-verity signatures using the platform > keyring, which is populated using the UEFI DB certificates. This is > useful for self-enrolled systems that do not use MOK, as the > secondary keyring which is already used for verification, if the > relevant kconfig is enabled, is linked to the machine keyring, which > gets its certificates loaded from MOK. On datacenter/virtual/cloud > deployments it is more common to deploy one's own certificate chain > directly in DB on first boot in unattended mode, rather than relying > on MOK, as the latter typically requires interactive authentication > to enroll, and is more suited for personal machines. I think that's true if you roll your own cloud OS. If you rely on a distro OS (as, say, IBM Cloud does) you do use shim/mok and actually you als have to enroll all the driver module keys in MoK. > Default to the same value as > DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING > if not otherwise specified, as it is likely that if one wants to use > MOK certificates to verify dm-verity volumes, DB certificates are > going to be used too. Keys in DB are allowed to load a full kernel > already anyway, so they are already highly privileged. But there's a reason we allow mok users to distrust DB through mokutil. It's because although you might be OK with these keys guarding the pre- boot environment (because if they don't do that Microsoft will be unhappy) and transferring control to SHIM via these keys, you wouldn't necessarily trust the owner of these keys to tamper with your kernel or install modules. Doesn't a similar reasoning apply to dm-verity root hash signing? By the way, if I look at how the machine keyring is handled, db certs won't get added if MokIgnoreDB is set by shim, so I think the behaviour of this patch is correct, and it's just the wording above that may be misleading. James
