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

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Mar 05, 2026 at 03:18:09PM -0500, James Bottomley wrote:
> On Thu, 2026-03-05 at 10:51 -0800, Eric Biggers wrote:
> > 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?
> 
> Well, I didn't say kernel, I said LSM.  The problem is that the last
> hook in the LSM chain for eBPF loading occurs before the loader has
> actually run.  This means that either the LSM needs to be assured
> verification will complete (by running it itself), which is what the
> patch set I pointed to does; or that we need an additional verification
> hook in eBPF somewhere in the verifier after the loader has run, which
> the eBPF people are looking at but haven't actually found anything yet.
> 
> The OID helps the LSM do the additional verification without changing
> any of the eBPF loading flow.

LSMs are part of the kernel.

Not sure I follow.  How can the kernel verify something before it's been
loaded into the kernel?

- Eric