Re: [PATCH bpf-next v3 04/15] lsm: Add the bpf_lsm_policy_release kfunc and policy object destructor

[Justin Suess]

On Wed, Sep 09, 2026 at 05:34:31PM -0400, Paul Moore wrote:
> On Wed, Sep 9, 2026 at 3:37 PM Justin Suess <utilityemal77@xxxxxxxxx> wrote:
> >
> > Add security/bpf_lsm_kfuncs.c, the home of the kfuncs exposing LSM
> > policy objects to BPF programs, with the first of them:
> >
> >   bpf_lsm_policy_release(object)                KF_RELEASE
> >
> > The kfuncs are the LSM framework's own BPF interface: there is no
> > per-LSM kfunc and no intermediate security_*() layer.  Each kfunc
> > walks the matching hook's implementation list and calls the one
> > registered by the LSM whose lsmid the policy object carries.  Calling
> > a kfunc for an LSM that is not active or has no policy object support
> > fails at runtime rather than hiding the kfunc at verification time,
> > so BPF program loading is independent of the boot-time LSM
> > configuration.
> >
> > A policy object reference is meant to be handed over through a map
> > kptr field, so also register a destructor for struct
> > lsm_policy_object: map-held references are dropped on map teardown,
> > possibly from a context that cannot sleep, which the
> > policy_object_put() hook contract accounts for.  For the same reason
> > the kfunc is not KF_SLEEPABLE, and the filter adds no per-kfunc rule:
> > releasing a reference must be allowed wherever one can be held.  The
> > filter itself is needed because BPF_PROG_TYPE_LSM and
> > BPF_PROG_TYPE_SYSCALL, the two registered program types, share their
> > kfunc lookup buckets with other program types.
> >
> > Cc: Paul Moore <paul@xxxxxxxxxxxxxx>
> > Cc: KP Singh <kpsingh@xxxxxxxxxx>
> > Signed-off-by: Justin Suess <utilityemal77@xxxxxxxxx>
> > ---
> >
> > Notes:
> >     v2->v3:
> >         - No change.
> >
> >  MAINTAINERS               |  1 +
> >  security/Makefile         |  2 +-
> >  security/bpf_lsm_kfuncs.c | 98 +++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 100 insertions(+), 1 deletion(-)
> >  create mode 100644 security/bpf_lsm_kfuncs.c
> 
> While not a new concern, it has been a few months so I want to mention
> it again to see where things stand with the BPF crowd: are the BPF
> folks still opposed to BPF kfuncs in security/bpf_lsm_kfuncs.c,
> similar to fs/bpf_fs_kfuncs.c?
> 
> If the answer remains yes, the BPF devs are not able to tolerate
> kfuncs under security/, then I'm afraid this patchset is stuck.
> However, if the BPF devs are willing to ACK kfuncs in
> security/bpf_lsm_kfuncs.c, I'll add this patchset to the review queue
> for the LSM tree.
>
To avocate for the current placement:

Placing these kfuncs outside where it is in security/ would
be very awkward, the kfuncs use lsm internal APIs
(lsm_for_each_hook, active static keys, lsm dispatch table) that
have no buisness outside the LSM framework.

And logically, the kfuncs operate entirely on in-tree lsm objects.

> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6215fcb07770..ba816d7ee127 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5081,6 +5081,7 @@ F:        kernel/bpf/bpf_lsm.c
> >  F:     kernel/bpf/bpf_lsm_proto.c
> >  F:     kernel/trace/bpf_trace.c
> >  F:     security/bpf/
> > +F:     security/bpf_lsm_kfuncs.c
> 
> We would need the maintenence of security/bpf_lsm_kfuncs.c to fall to
> the LSM framework, just as the maintenence of bpf_fs_funcs.c falls to
> the VFS.
>
Agreed.

I intend that any security/ kfuncs go through both LSM and BPF
review at a minimum. As a bug in any of these kfuncs or their permitted
calling context / signatures could cause regressions in either subsystem.

Justin
>   % ./scripts/get_maintainer.pl -f fs/bpf_fs_kfuncs.c
>   Alexander Viro
>   Christian Brauner
>   Jan Kara
>   linux-fsdevel@vger
>   linux-kernel@vger
> 
> -- 
> paul-moore.com