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

[Alexei Starovoitov]

On Thu, Oct 9, 2025 at 1:47 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Tue, Oct 7, 2025 at 9:53 AM KP Singh <kpsingh at kernel.org> wrote:
> > On Mon, Oct 6, 2025 at 5:08 AM Paul Moore <paul at paul-moore.com> wrote:
> > > On Fri, Oct 3, 2025 at 12:25 PM KP Singh <kpsingh at kernel.org> wrote:
> > > > On Fri, Oct 3, 2025 at 4:36 AM Paul Moore <paul at paul-moore.com> wrote:
> > > > > On Thu, Oct 2, 2025 at 9:48 AM KP Singh <kpsingh at kernel.org> wrote:
> > > > > > On Wed, Oct 1, 2025 at 11:37 PM Paul Moore <paul at paul-moore.com> wrote:
>
> ...
>
> > I feel we will keep going in circles on this and I will leave it up to
> > the maintainers to resolve this.
>
> Yes, I think we can all agree that the discussion has reached a point
> where both sides are simply repeating ourselves.
>
> I believe we've outlined why the code merged into Linus' tree during
> this merge window does not meet the BPF signature verification
> requirements of a number of different user groups, with Blaise
> proposing an addition to KP's code to satisfy those needs.  Further, I
> believe that either Blaise, James, or I have responded to all of KP's
> concerns regarding Blaise's patchset, and while KP may not be happy
> with those answers, no one has yet to offer an alternative solution to
> Blaise's patchset.
>
> With that in mind, I agree with KP that it's time for "the maintainers
> to resolve this".  Alexei, will you be merging Blaise's patchset and
> sending it up to Linus?

Nope. Both you and James did not understand what Blaise
patch set is actually doing, and that followed the whole set of
arguments and reasons that made no sense.

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.
Both allocate and populate kernel memory with data.
For kernel module it's bss, data, rodata.
For bpf it's BTF, maps.
Then the kernel applies relocations to .text against .data and against
the kernel.
bpf is doing the same. It applies relocation against maps, btf, kfuncs.

The only difference here is that ko loading is done by
kernel/module/main.c which is pretty complex on its own,
since it's parsing ELF, symbols, etc
While bpf loader is doing a fraction of that.
It doesn't need to parse ELF. It's a dumb sequence of commands:
load mapA, load mapB, apply relocation at off N to prog M.
If bpf loader has a bug it will still be caught by the verifier,
since it effectively runs multiple times. Once for loader prog,
and then for each prog that loader wants to load.

For kernel modules and for bpf we trust the build system to be correct.
gcc, clang, linker, objtool, pahole, various scripts/* need to do the
right thing for the kernel modules.
In bpf case it's only libbpf that is trusted to produce
valid loader bpf program for a set of bpf programs and maps.
I share the discomfort that tools/lib/bpf/gen_loader.c
is doing something that you don't understand,
but, really, do you understand what gcc, clang, objtool are doing?
You have to trust the build process otherwise it's all pointless.
Malicious "gcc" can inject special code into a signed kernel module.
Malicious "libbpf" can inject something into "loader prog",
but again the verifier is still there even if "loader prog" is busted.