On Mon, Oct 27, 2025 at 6:45 PM Song Liu <[email protected]> wrote: > 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.
You might not want to wait on a comment from Eric :) > > 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? Good to know, I wasn't aware that Matt was also listed as a maintainer for the BPF LSM. In that case as long as there is an ACK, not just a reviewed tag, I think that should be sufficient. > > 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. If the BPF LSM isn't going to maintain any state in the lsm_prop struct, I'd rather see the associated LSM interfaces disabled from being used in a BPF LSM just so we don't run into odd expectations in the future. Maybe they are already disabled, I haven't checked. If you want to keep those interfaces/hooks enabled for a BPF LSM, just keep the lsm_prop_bpf struct/field. -- paul-moore.com
