[PATCH bpf-next v2 1/5] bpf: Verify signed loader metadata at load time

[Paul Moore]

On Fri, Jun 26, 2026 at 6:01 PM KP Singh <kpsingh at kernel.org> wrote:
> On Fri, Jun 26, 2026 at 3:16 AM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
> > On Thu Jun 25, 2026 at 5:59 PM PDT, Paul Moore wrote:
> > >
> > > For all the reasons I gave previously, I can't support moving the
> > > existing security_bpf_prog_load() hook at this point in time.
> >
> > Paul,
> > it's not up to you to approve or deny where security_bpf_prog_load()
> > is called within bpf subsystem as long as it doesn't affect behavior.
> > Daniel's patch doesn't change observable state from LSMs pov.
> > It merely moves the call from syscall.c to verifier.c.
> > So we're going to proceed.
> >
> > > I'm guessing you still haven't looked at Blaise's patchset from last
> > > September.
> >
> > Blaise approach was Nacked because you guys ignored TOCTOU issue.
> > I pointed it a year ago before AI was a thing. Then sashiko
> > pointed it again and the bot explained it in detail. It was again
> > ignored.
>
> Agreed, with Alexei: I like Daniel's solution because it avoids the
> complexity of machine independent BTF for loader programs and still
> addresses the signing goal, without the TOCTOU. I am okay with the
> current implementation as well. I think having kfuncs in loader
> programs would be useful, but we don't need to rush it or tie it to
> the signing effort.

As I've said a couple of times now in Daniel's approach, I like the
basic idea in Daniel's approach; it aligns with the same scheme we
have been advocating for all along: run the PKCS7 signature over both
the lskel loader and the maps.  I know you keep mentioning a TOCTOU
bug in that September patchset, but the main objection to all the
different variants of Blaise's patches was always the same basic idea:
you and Alexei wanted to verify the maps in the lskel loader BPF code,
while we wanted to directly verify the maps as part of the PKCS7
signature.  Any TOCTOU issues were implementation details; the
difference in the signature scheme was the sticking point in many of
the arguments.  For whatever it is worth, you and Alexei were not
immune to TOCTOU issues either.  The frozen map problem was mentioned
on-list and ignored.  We had to submit a PoC/report to security at kernel
to get it taken seriously and patched.

Regardless, of how we got here and whether or not you recognize
Daniel's signature scheme as a retread of Blaise's scheme, the point
is that you've come around to a concept we have advocated for over a
year.  If you plan to merge it, good (although I do wonder what Linus
will think of the userspace breakage caused by abandoning the
signature scheme that shipped in v6.18, maybe it's not a big deal, who
knows).  However, and this is important, we can't move the
security_bpf_prog_load() function to where Daniel proposed in his v2
patchset.  The issue is that non-trivial work happens, e.g. the
potential allocation of a buffer to hold up to one million eBPF
instructions, and we want to ensure we have an LSM access control
point before that happens.  If you, Daniel, and Alexei want to move
the bpf_prog_verify_signature() call into the verifier that's fine.
However, the security_bpf_prog_load() call needs to stay where it is.
It served an important purpose well before signed BPF programs were
supported, and adding BPF signatures doesn't invalidate that original
purpose.  If you want an LSM hook *after* the
bpf_prog_verify_signature() call and you oppose adding a new hook for
this new functionality, use the security_bpf_prog() hook.  It isn't
quite as conceptually clean of a solution as adding a new hook, but it
should work to allow you to control access to a BPF program based on
the signature verification result.

I'll support Daniel's patchset as long as you don't tamper with the
security_bpf_prog_load() hook.  If you move the hook to where it is
currently proposed in Daniel's v2 patchset I will have to object.  Do
we really want to keep going around on this stupid, petty carousel of
bickering and constant NACKs?

-- 
paul-moore.com