[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 3:37 PM Justin Suess <utilityemal77 at 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 at paul-moore.com>
> Cc: KP Singh <kpsingh at kernel.org>
> Signed-off-by: Justin Suess <utilityemal77 at 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.

> 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.

  % ./scripts/get_maintainer.pl -f fs/bpf_fs_kfuncs.c
  Alexander Viro
  Christian Brauner
  Jan Kara
  linux-fsdevel at vger
  linux-kernel at vger

-- 
paul-moore.com