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

[Paul Moore]

On Sat, Sep 12, 2026 at 3:33 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
> On Fri Sep 11, 2026 at 10:26 PM PDT, Justin Suess wrote:
> >
> > If fs/, mm/, drivers/, net/, are permitted to have kfuncs, then why not
> > security/? kfuncs.rst doesn't seem to forbid this.
>
> because fs, mm, net see the value in bpf. bpf helps these subsytems
> to focus on their core technologies and moves policy decisions out of
> kernel and into bpf.
> while lsm people treat bpf as arch-enemy.

It's amusing to read this when just this week we merged a patchset
into the LSM tree for the benefit of those writing BPF LSMs.  If you
look at the discussion around patch 2/2 you will even see a reasonable
exchange between Matt Bobrowski, a BPF LSM maintainer, and me about
the patch.  Alexei is obviously welcome to his own opinion, but I
would encourage those reading this thread to look beyond his comments.

https://lore.kernel.org/linux-security-module/20260904-lsm-mount-idmaps-v3-0-920a1963675d@xxxxxxxxxxxx/

> kfuncs are not stable. we keep refactoring them.
> while lsm folks treat anything within *lsm* and *security* as stable apis.

Most everyone involved in LSM development knows that statement is
simply incorrect.  A quick glance at the git log, our process
guidelines on modifying LSM hooks (look in the MAINTAINERS file for a
pointer), or even just the patch I referenced above should provide
quick confirmation.

-- 
paul-moore.com