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

[Justin Suess <utilityemal77@gmail.com>]

On Fri, Sep 11, 2026 at 08:37:22PM -0700, Alexei Starovoitov wrote:
> On Wed Sep 9, 2026 at 4:08 PM PDT, Paul Moore wrote:
> > On Wed, Sep 9, 2026 at 6:21 PM Justin Suess <utilityemal77@gmail.com> 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@gmail.com> 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@paul-moore.com>
> >> > > Cc: KP Singh <kpsingh@kernel.org>
> >> > > Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> >> > > ---
> >> > >
> >> > > 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.
> 
> There is will be no kfuncs under security/.
> Period.
> 
Howdy Alexei,

If fs/, mm/, drivers/, net/, are permitted to have kfuncs, then why not
security/? kfuncs.rst doesn't seem to forbid this.

Placement in security/, on my initial thought, was the most logically relevant place
for kfuncs that interact with in-tree LSMs, as we place fs kfuncs under fs/,
net kfuncs under net/ etc.

Where would you point me to?

Thanks,
Justin