On Thu, Jun 25, 2026 at 4:44 PM Alexei Starovoitov <[email protected]> wrote: > On Thu, Jun 25, 2026 at 1:40 PM Paul Moore <[email protected]> wrote: > > On Thu, Jun 25, 2026 at 3:58 PM Alexei Starovoitov > > <[email protected]> wrote: > > > On Thu, Jun 25, 2026 at 7:23 AM Christian Brauner <[email protected]> > > > wrote: > > > > On 2026-06-23 20:12:32-04:00, Paul Moore wrote: > > > > > On Jun 18, 2026 David Windsor <[email protected]> wrote: > > > > > > > > > > > Add bpf_init_inode_xattr() kfunc for BPF LSM programs to atomically > > > > > > set > > > > > > xattrs via the inode_init_security hook using lsm_get_xattr_slot(). > > > > > > > > > > > > The inode_init_security hook previously took the xattr array and > > > > > > count > > > > > > as two separate output parameters (struct xattr *xattrs, int > > > > > > *xattr_count), which BPF programs cannot write to. Pass the xattr > > > > > > state > > > > > > as a single context object (struct xattr_ctx) instead, and have > > > > > > bpf_init_inode_xattr() take that context directly. Update the > > > > > > existing > > > > > > in-tree callers of inode_init_security to take and forward the new > > > > > > xattr_ctx. > > > > > > > > > > > > A previous attempt [1] required a kmalloc string output protocol for > > > > > > the xattr name. Since commit 6bcdfd2cac55 ("security: Allow all > > > > > > LSMs to > > > > > > provide xattrs for inode_init_security hook") [2], the xattr name > > > > > > is no > > > > > > longer allocated; it is a static constant. > > > > > > > > > > > > Because we rely on the hook-specific ctx layout, the kfunc is > > > > > > restricted to lsm/inode_init_security. Restrict the xattr names that > > > > > > may be set via this kfunc to the bpf.* namespace. > > > > > > > > > > > > Link: > > > > > > https://kernsec.org/pipermail/linux-security-module-archive/2022-October/034878.html > > > > > > [1] > > > > > > Link: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bcdfd2cac55 > > > > > > [2] > > > > > > Suggested-by: Song Liu <[email protected]> > > > > > > Signed-off-by: David Windsor <[email protected]> > > > > > > --- > > > > > > fs/bpf_fs_kfuncs.c | 106 > > > > > > +++++++++++++++++++++++++++++- > > > > > > include/linux/bpf.h | 1 + > > > > > > include/linux/bpf_lsm.h | 3 + > > > > > > include/linux/evm.h | 9 +-- > > > > > > include/linux/lsm_hook_defs.h | 4 +- > > > > > > include/linux/lsm_hooks.h | 16 ++--- > > > > > > include/linux/security.h | 5 ++ > > > > > > kernel/bpf/bpf_lsm.c | 10 +++ > > > > > > kernel/bpf/trampoline.c | 3 + > > > > > > security/bpf/hooks.c | 1 + > > > > > > security/integrity/evm/evm_main.c | 8 ++- > > > > > > security/security.c | 7 +- > > > > > > security/selinux/hooks.c | 4 +- > > > > > > security/smack/smack_lsm.c | 27 ++++---- > > > > > > 14 files changed, 166 insertions(+), 38 deletions(-) > > > > > > > > > > I have a few specific comments below, inline with the patch, but I > > > > > wanted > > > > > to make some general comments too. > > > > > > > > > > The kfunc additions really don't belong in the VFS kfunc file, please > > > > > create a LSM kfunc file (call it security/bpf_lsm_kfuncs.c) and add > > > > > the > > > > > kfunc code to this new file. > > > > > > > > We expose a bunch of VFS heavy operations for various security modules > > > > and this is really not different. For xattrs we have it all centralized > > > > in the VFS and in general all VFS related bpf kfuncs should continue > > > > living there and be registered there. Anything that's just bpf infra > > > > specific can go to security/bpf/kfuncs.c instead. But anyway, it's a bpf > > > > specific helper so it's the bpf maintainer's call. > > > > > > Completely agree. This is vfs related kfunc and has to be > > > in fs/bpf_fs_kfuncs.c to make sure vfs maintainers review it now > > > and all future changes to it. > > > > *laughs* > > > > Okay, then split out the LSM specific stuff into > > security/bpf_lsm_kfuncs.c; all the LSM macros/defines/calls should be > > in the LSM kfuncs file. > > Paul, > > I'm sorry, but you didn't demonstrate the level of understanding > of bpf to be trusted to maintain any piece of it.
Alexei, You haven't demonstrated the understanding or decorum necessary to be entrusted with any part of the LSM framework. -- paul-moore.com
