[PATCH bpf-next v2 0/3] BPF signature hash chains

[James Bottomley]

On Tue, 2025-10-07 at 15:53 +0200, KP Singh wrote:
> On Mon, Oct 6, 2025 at 5:08 AM Paul Moore <paul at paul-moore.com>
> wrote:
[...]
> > * Do you understand how your signature scheme only verifies the
> > loader BPF program before the security_bpf_prog_load() LSM hook,
> > meaning the original BPF program has had no integrity or provenance
> > verification when security_bpf_prog_load() is called?
> 
> Yeah, this loader is signed to load only specific trusted payload.
> You are wrong about it not having integrity. The integrity checking
> happens in the loader that the very entity that signed the payload of
> the loader which contains:
>  
> * The hash of the loaded programs and metadata.
> * An integrity check that verifies this hash before loading the
> programs.
> 

I think this point is understood generally.  However, the rub for LSM
is that the verification of the program map by the loader happens
*after* the security_bpf_prog_load() hook has been called.  So there's
no way for the hook to a) know if the program will actually verify
because that final check occurs after it was called or b) leave an
audit trail of a program map verification failure which could be caused
by an attempt to tamper with the program and should be logged through
the security audit channels.

> I feel we will keep going in circles on this and I will leave it up
> to the maintainers to resolve this.

I think this is because what LSM is looking for isn't just signing,
it's full determination that all the integrity conditions it is
imposing are satisfied by the time the hook is called.  From the flow I
describe above this isn't happening.

Regards,

James