On Mon, Oct 27, 2025 at 2:14 PM Paul Moore <[email protected]> wrote: > > On Fri, Oct 24, 2025 at 8:10 PM Song Liu <[email protected]> wrote: > > > > lsm_prop_bpf is not used in any code. Remove it. > > > > Signed-off-by: Song Liu <[email protected]> > > > > --- > > > > 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/[email protected]/
