[RFC bpf-next] lsm: bpf: Remove lsm_prop_bpf

[Song Liu]

On Mon, Oct 27, 2025 at 2:14 PM Paul Moore <paul at paul-moore.com> wrote:
>
> On Fri, Oct 24, 2025 at 8:10 PM Song Liu <song at kernel.org> wrote:
> >
> > lsm_prop_bpf is not used in any code. Remove it.
> >
> > Signed-off-by: Song Liu <song at kernel.org>
> >
> > ---
> >
> > Or did I miss any user of it?
> > ---
> >  include/linux/lsm/bpf.h  | 16 ----------------
> >  include/linux/security.h |  2 --
> >  2 files changed, 18 deletions(-)
> >  delete mode 100644 include/linux/lsm/bpf.h
>
> You probably didn't miss any direct reference to lsm_prop_bpf, but the
> data type you really should look for when deciding on this is
> lsm_prop.  There are a number of LSM hooks that operate on a lsm_prop
> struct instead of secid tokens, and without a lsm_prop_bpf
> struct/field in the lsm_prop struct a BPF LSM will be limited compared
> to other LSMs.  Perhaps that limitation is okay, but it is something

I think audit is the only user of lsm_prop (via audit_names and
audit_context). For BPF based LSM or audit, I don't think we need
specific lsm_prop. If anything is needed, we can implement it with
task local storage or inode local storage.

CC audit@ and Eric Paris for more comments on audit side.

> that should be discussed; I see you've added KP to the To/CC line, I
> would want to see an ACK from him before I merge anything removing
> lsm_prop_bpf.

Matt Bobrowski is the co-maintainer of BPF LSM. I think we are OK
with his Reviewed-by?

> I haven't checked to see if the LSM hooks associated with a lsm_prop
> struct are currently allowed for a BPF LSM, but I would expect a patch
> removing the lsm_prop_bpf struct/field to also disable those LSM hooks
> for BPF LSM use.

I don't think we need to disable anything here. When lsm_prop was
first introduced in [1], nothing was added to handle BPF.

Thanks,
Song

[1] https://lore.kernel.org/linux-security-module/20241009173222.12219-1-casey@schaufler-ca.com/