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

[Paul Moore]

On Thu, Jun 25, 2026 at 4:37 PM Daniel Borkmann <daniel at iogearbox.net> wrote:
> On 6/24/26 8:42 PM, Paul Moore wrote:
> > On Wed, Jun 24, 2026 at 11:37 AM Daniel Borkmann <daniel at iogearbox.net> wrote:
> >> On 6/24/26 5:12 PM, Paul Moore wrote:
> >>> On Wed, Jun 24, 2026 at 10:03 AM Daniel Borkmann <daniel at iogearbox.net> wrote:
> >> [...]
> >>>>    include/linux/bpf_verifier.h |   1 +
> >>>>    kernel/bpf/syscall.c         |  76 +---------------
> >>>>    kernel/bpf/verifier.c        | 163 ++++++++++++++++++++++++++++++++++-
> >>>>    3 files changed, 165 insertions(+), 75 deletions(-)
> >>>
> >>> ...
> >>>
> >>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> >>>> index b44106c8ea75..026b61d78bdb 100644
> >>>> --- a/kernel/bpf/syscall.c
> >>>> +++ b/kernel/bpf/syscall.c
> >>>> @@ -3189,10 +3121,6 @@ static int bpf_prog_load(union bpf_attr *attr, bpfptr_t uattr, struct bpf_log_at
> >>>>           if (err < 0)
> >>>>                   goto free_prog;
> >>>>
> >>>> -       err = security_bpf_prog_load(prog, attr, token, uattr.is_kernel);
> >>>> -       if (err)
> >>>> -               goto free_prog;
> >>>> -
> >>>>           /* run eBPF verifier */
> >>>>           err = bpf_check(&prog, attr, uattr, attr_log);
> >>>>           if (err < 0)
> >>>
> >>> We must preserve the existing location of the call into the
> >>> security_bpf_prog_load() hook as some users rely on this hook being
> >>> called *before* the verifier runs.
> >>
> >> Keep in mind that the verifier /at this point/ of the new location did
> >> _not_ verify anything. So there is no heavy-duty work happening yet at
> >> security_bpf_prog_load. The work that is done before security_bpf_prog_load
> >> is basically setting up the env, initializing the verifier log, and doing
> >> the process_fd_array which is resolving the map/BTF objects. But it did
> >> not walk any instructions etc, so semantics of the security_bpf_prog_load
> >> hook did not change from a user PoV.
> >
> > There is still a reasonable amount of work between the existing and
> > new call sites, and the existing location outside of bpf_check()
> > offers an additional robustness benefit that future verifier changes
> > are less likely to impact the hook.  If I'm completely honest, I also
> > need to consider the events of the past year and a half; I'm now much
> > less inclined to support LSM hook changes in the BPF subsystem because
> > I'm very concerned about our ability to revert/modify those changes in
> > the future if needed.  That doesn't mean I won't support LSM hook
> > changes in BPF, but such changes are going to need to have a *very*
> > strong advantage from a LSM perspective to offset the risk associated
> > with the current BPF subsystem.
>
>  From where you sit with regards to LSMs that is a natural stance towards
> all kernel code, but coming back to the LSM hook, to me this is way too
> excessive that we should add *yet another* LSM hook ...

For all the reasons I gave previously, I can't support moving the
existing security_bpf_prog_load() hook at this point in time.
However, unlike Alexei, I am willing to work with you to develop a new
LSM hook to meet your new needs for enforcing signed BPF program
policies via an LSM (BPF or otherwise).  If, as you say, you are not
willing to add a new hook, you will need to find a way to make it work
with the existing hooks/placements.

> > I also have to bring up the same question I asked back in your v1
> > posting: have you discussed this signature approach with Alexei?  Your
> > patches abandon and remove KP's signature scheme in favor of what is
> > effectively Blaise's signature scheme from last fall; Alexei argued
> > very strongly against these changes in the past.  I'd hate to spend a
> > lot more time reviewing and discussing patches that Alexei is simply
> > going to NACK once again.
>
> I think last time I already stated that this is not "effectively Blaise's
> signature scheme" for couple of reasons ...

I already responded to these three points in your last patchset.  It
was sent to you directly, as well as to all of the relevant lists (it
was a reply-all), but here is a lore link if you haven't read it:

https://lore.kernel.org/linux-security-module/CAHC9VhQQKNvP1Who0DdUc0EsVYd_JoSneyzOHZ=Q0MP2qQndCw@mail.gmail.com/

>  From where you started out back then, it was the stance that while the
> original KP approach generically addresses all the use cases for loading
> BPF related to relocations via the lskel loader, Blaise proposed a parallel
> scheme which would only allow static programs (only insns, no maps) ...

I'm guessing you still haven't looked at Blaise's patchset from last
September.  You were CC'd on the original posting, and I sent you a
lore link in our discussion of your v1 patchset, but I guess it's easy
to get busy/distracted and lose track of things.  Regardless, here is
another link to Blaise's patchset:

https://lore.kernel.org/linux-security-module/20250929213520.1821223-1-bboscaccy@linux.microsoft.com/

Blaise's patchset proposed a scheme which ran the PKCS7 signature over
the lskel loader and maps in a way *very* similar to what you are
proposing.  Blaise's patchset also supported the same key selection as
KP's scheme so user and session signatures were supported without
issue.

> ... So I cannot
> directly speak for Alexei/KP, but I think this proposal should satisfy all
> parties under one roof.

Considering the striking similarities between what you are proposing
and what Blaise proposed last September I *strongly* suggest getting a
basic thumbs-up or thumbs-down from Alexei on this new/old approach
on-list.  As you can see from the lore archives, he has vehemently
opposed the approach you are proposing for quite a while.  If he has
changed his mind to understand the value in Blaise's approach of
running the PKCS7 signature over both the lskel loader and maps that's
great, but I worry that will not be the case.

-- 
paul-moore.com