Re: [PATCH v3 0/5] pkcs7: better handling of signed attributes

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Mar 05, 2026 at 09:46:42AM -0500, James Bottomley wrote:
> On Wed, 2026-03-04 at 23:55 -0800, Eric Biggers wrote:
> > On Thu, Feb 26, 2026 at 07:43:54AM -0500, James Bottomley wrote:
> > > > If this is for some out-of-tree module, we don't do that.
> > > > 
> > > > I'll also note that we should generally be aiming to simplify the
> > > > PKCS#7 signature verification code, not making it even more
> > > > complex.
> > > 
> > > I'm fine with the general goal, but since the current code verifies
> > > the signature, pulls out the message hash and other attributes,
> > > compares the message against the MessageDigest one and then frees
> > > the whole structure it's a bit hard to see how the current goal can
> > > be achieved without extracting at least the first part of that ...
> > > but if you have   suggestion, I'm happy to implement.
> > 
> > Sure, just incorporate your auxiliary data into the actual message
> > being signed and verified.  Something like:
> >     
> >     program_len || program || hash*
> 
> We can't do that because the second hash is for the LSM.  If there's no
> LSM then we need the signature to pass the current eBPF signature check
> because the second hash will be verified by the loader, which means the
> program hash and nothing else must be in the messageDigest attr.
> 

Why does the loader need to verify the signature if the kernel has to do
it anyway, and why does the loader need to skip verifying the maps?

- Eric