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

[Paul Moore]

On Wed, Sep 9, 2026 at 6:21 PM Justin Suess <utilityemal77@xxxxxxxxx> wrote:
> 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.

While some other subsystems are lax on this, it's general practice in
the LSM space to *really* try to get ACK's from other affected
subsystems before merging.  Sometimes we move forward anyway, e.g.
patches being ignored for almost a year, but those are exceptions
rather than the rule.

I only bring this up because the MAINTAINERS entry was pointed at the
BPF devs, not the LSM devs.  I would expect that patches going into
security/bpf_lsm_kfuncs.c would need to be ACK'd both the LSM
framework and BPF LSM maintainers.

-- 
paul-moore.com