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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

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.