Re: [GIT PULL] BPF changes for 7.4

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed, Oct 21, 2026 at 02:26 PM Paul Moore <paul@paul-moore.com> wrote:
>
> The primary reason for my objection is that the bpf_inode_init_xattr()
> kfunc, despite its name, is a LSM kfunc and should be located in
> security/bpf_lsm_kfuncs.c.

Linus,

there is no such file. The ask is to create it and to give it to LSM tree:
"We would need the maintenence of security/bpf_lsm_kfuncs.c to fall to
the LSM framework"
https://lore.kernel.org/all/CAHC9VhQHZ+ngFdzKqmnzBh341CGEg-jexu+QYU8=1qXK=u-x-Q@mail.gmail.com/

fs/bpf_fs_kfuncs.c has six xattr kfuncs already:
bpf_{get,set,remove}_dentry_xattr(), bpf_get_file_xattr(),
bpf_cgroup_read_xattr(), bpf_sock_read_xattr().
bpf_inode_init_xattr() is the 7th. Same "security.bpf." names,
same check of the name.
Christian's answer to the same ask in June:
"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."
https://lore.kernel.org/bpf/20260625-schnabel-rennmaschine-parieren-bcb352c3cf59@brauner/

> The bpf_inode_init_xattr() kfunc does not call into any VFS APIs, but it
> does call into an LSM internal API.

That API is lsm_get_xattr_slot(), a static inline in
include/linux/lsm_hooks.h:

	if (unlikely(!xattrs))
		return NULL;
	return &xattrs[(*xattr_count)++];

The kdoc of security_inode_init_security() tells LSMs to call it.
selinux, smack and evm do. BPF LSM is one more LSM.
The series doesn't touch LSM framework. All it has under security/ is:
 security/bpf/hooks.c |  1 +

The kfunc fills struct xattr for initxattrs() callback of the filesystem.
It runs inside the transaction that creates the inode.

> it weould appear the decision to locate bpf_inode_init_xattr()
> in fs/bpf_fs_kfuncs.c is due largely (solely?) to a petulant policy to
> never allow a kfunc in the security/ space:

The kfunc is in fs/bpf_fs_kfuncs.c since David's v1 in April.
That email is from September.

On Jul 1 Paul was ok with the kfunc there as long as LSM bits move into
security_lsmxattr_add():
https://lore.kernel.org/all/CAHC9VhT37f5TwgksE_i0Yttpy3i7niBr6QrNVVmpwe_eGX428g@mail.gmail.com/
David did that in v5 and v6. On Jul 31:
"I saw the v5 patchset and the nature of the kfunc became painfully
obvious to me so I changed my opinion."
https://lore.kernel.org/all/CAHC9VhQ24fp7_sy1=NiWkfzPLSM35ugSCOKDKxnm6H9W-pDa6Q@mail.gmail.com/
"this puts us at a stalemate and David will need to find another
approach for his work."
https://lore.kernel.org/all/CAHC9VhQ5vSr6JK0xtNnP2cre+3bbW9GUT7kXwLAcctwNpPzwrA@mail.gmail.com/
Six versions in three months, stuck on the name of the file.
That's why I don't want bpf kfuncs under security/.

> I can't support the BPF maintainers actively circumventing
> review/oversight from LSM developers.

v3-v6 were on LSM list.
The last series is that other approach. Christian, KP and Matt were in cc.
LSM list was not. It should have been. Fair point. Will cc next time.

It's in linux-next since September. On Sep 23 Daniel asked for technical
comments or bugs:
https://lore.kernel.org/bpf/04fe4568-90cb-4aac-a21d-c0443e418b46@iogearbox.net/
None so far.