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

[Christian Brauner]

On Sun, Sep 13, 2026 at 07:24:14PM -0700, Alexei Starovoitov wrote:
> On Sun, Sep 13, 2026 at 5:10 PM Paul Moore <paul at paul-moore.com> wrote:
> >
> > On Sun, Sep 13, 2026 at 7:25 PM Alexei Starovoitov
> > <alexei.starovoitov at gmail.com> wrote:
> > > On Sun, Sep 13, 2026 at 12:41 PM Paul Moore <paul at paul-moore.com> wrote:
> > > > On Sat, Sep 12, 2026 at 3:33 PM Alexei Starovoitov
> > > > <alexei.starovoitov at gmail.com> 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@amutable.com/
> > >
> > > And that's an example of unacceptable land grab by LSM folks
> > > that I'm concerned about.
> >
> > I made sure that patchset was ACK'd or Reviewed-by'd a VFS maintainer,
> > a BPF LSM maintainer, and the Smack maintainer before merging (I
> > covered the LSM and SELinux parts).  You might want to double check
> > your definition of "land grab".
> 
> You're still missing the point.
> Christian could have landed it via vfs tree with your ack for security/*.
> You have no power over lsm hook changes within vfs.

Which tbf is generally how I like to handle thing especially since we
usually have a lot of changes. But I'm open to shared branches as well.

So I think we naturally have to modify existing LSM hooks. But it's
shared pain. Since we use BPF LSM heavily in systemd we generally have
to absorb such growing pains as well.