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

[Paul Moore]

On Fri, Oct 10, 2025 at 11:53 AM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Thu, 2025-10-09 at 18:00 -0700, Alexei Starovoitov wrote:
> [...]
> > James's concern is valid though:
> >
> > > 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.
> >
> > I understand the discomfort, but that's what the kernel module
> > loading process is doing as well, so you should be concerned with
> > both. Since both are doing pretty much the same work.
>
> OK, so let me push on this one point because I don't agree with what
> you say here.  The way kernel modules and eBPF load is not equivalent.
> The kernel module signatures go over a relocateable elf binary which is
> subsequently relocated after signature verification in the kernel by
> the ELF loader.  You can regard the ELF loader as being equivalent to
> the eBPF loader in terms of function, absolutely.  However for security
> purposes the ELF loader is a trusted part of the kernel security
> envelope and its integrity is part of the kernel integrity and we have
> a this single trusted loader for every module.  In security terms
> verification of the ELF object signature is sufficient to guarantee
> integrity of the module because the integrity of the ELF loader is
> already checked.
>
> The eBPF loader, by contrast, because it contains all the relocations,
> is different for every eBPF light skeleton.  This means it's not a
> trusted part of the kernel and has to be integrity checked as well.
> Thus for eBPF, the integrity check must be over both the loader and the
> program; integrity checking is not complete until the integrity of both
> has been verified.  If you sign only the loader and embed the hash  of
> the program into the loader that is a different way of doing things,
> but the integrity check is not complete until the loader does the hash
> verification which, as has been stated many times before, is *after*
> the load LSM hook has run.
>
> There are two potential solutions to this: complete the integrity check
> before running the load hook (Blaise's patch) or add a LSM hook to
> collect the integrity information from the run of the loader.  Neither
> of these is present in the scheme you put upstream.

As a bit of background for those who weren't following the related
threads earlier this year, the idea of an additional hook was
discussed this spring and it was rejected by Alexei.

https://lore.kernel.org/linux-security-module/CAADnVQ+wE5cGhy6tgmWgUwkNutueEsrhh6UR8N2fzrZjt-vb4g@mail.gmail.com/

-- 
paul-moore.com