On 13/10/2020 01:55, Jarkko Sakkinen wrote: > On Fri, Oct 09, 2020 at 11:50:03AM +0200, Mickaël Salaün wrote: >> Hi, >> >> What do you think about this patch? >> >> Regards, >> Mickaël >> >> On 02/10/2020 09:18, Mickaël Salaün wrote: >>> From: Mickaël Salaün <mic@xxxxxxxxxxxxxxxxxxx> >>> >>> Add a new DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING configuration >>> to enable dm-verity signatures to be verified against the secondary >>> trusted keyring. This allows certificate updates without kernel update >>> and reboot, aligning with module and kernel (kexec) signature >>> verifications. > > I'd prefer a bit more verbose phrasing, not least because I have never > really even peeked at dm-verity, but it is also a good practice. > > You have the middle part of the story missing - explaining the semantics > of how the feature leads to the aimed solution. OK, what about: Add a new configuration DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING to enable dm-verity signatures to be verified against the secondary trusted keyring. Instead of relying on the builtin trusted keyring (with hard-coded certificates), the second trusted keyring can include certificate authorities from the builtin trusted keyring and child certificates loaded at run time. Using the secondary trusted keyring enables to use dm-verity disks (e.g. loop devices) signed by keys which did not exist at kernel build time, leveraging the certificate chain of trust model. In practice, this allows to update certificates without kernel update and reboot, aligning with module and kernel (kexec) signature verification which already use the secondary trusted keyring.
