On Thu, 26 Sept 2024 at 17:02, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > On Wed, 25 Sep 2024, Luca Boccassi wrote: > > > > > diff --git a/drivers/md/dm-verity-verify-sig.c b/drivers/md/dm-verity-verify-sig.c > > > > index d351d7d39c60..a9e2c6c0a33c 100644 > > > > --- a/drivers/md/dm-verity-verify-sig.c > > > > +++ b/drivers/md/dm-verity-verify-sig.c > > > > @@ -127,7 +127,7 @@ int verity_verify_root_hash(const void *root_hash, size_t root_hash_len, > > > > #endif > > > > VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL); > > > > #ifdef CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING > > > > - if (ret == -ENOKEY) > > > > + if (ret == -ENOKEY || ret == -EKEYREJECTED) > > > > ret = verify_pkcs7_signature(root_hash, root_hash_len, sig_data, > > > > sig_len, > > > > VERIFY_USE_PLATFORM_KEYRING, > > > > -- > > > > 2.39.5 > > > > > > Hi > > > > > > Please describe what problem does this patch solve. I.e. why would anyone > > > put a key into the trusted keyring that could sign the roothash and > > > restrict its usage so that it can't be used to sign the roothash? > > > > > > In the other places of the kernel, only -ENOKEY is tested: > > > kexec_kernel_verify_pe_sig: > > > if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) > > > s390_verify_sig: > > > if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) > > > do they need to be converted to -EKEYREJECTED too? > > > > To be perfectly honest, I do not have a use case for the EKEYREJECTED > > fallback - it was suggested by Serge when I was working on the IPE > > keyrings usage: > > > > https://lore.kernel.org/all/20240920020217.GA528455@xxxxxxxxxxxxxxx/ > > > > I would like to maintain the usage of keyrings in sync between the two > > components given they are used together, for consistency, so I > > counter-proposed to send the change to dmverity first. I am following > > up on that promise with this patch. > > If there are reasons not to take this change, or if there are no > > convincing reasons to take it, I do not have strong opinions either > > way so I don't mind what the outcome is either way, as I am just > > following up on that review comment. I'll let Serge explain the > > reasoning for the request, if he wants to do it. > > > > If this change is accepted, I will send the same for IPE. If not, I > > won't. I do not directly use other subsystems that use these keyrings, > > so I will not send changes for those even if this goes in. > > Hi > > I accepted this patch, I'll send it to Linus with other device mapper > patches. > > Mikulas Thank you!
