[GIT PULL] BPF changes for 7.4

[Paul Moore]

On Wed, Oct 21, 2026 at 5:01 PM Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
>
> Hi Linus,
>
> The following changes since commit ff47652a4b66c067c765a7ad464d930b5a9367cc:
>
>   Merge tag 'cifs-fixes-7.3-rc6' of https://git.manguebit.org/linux (2026-10-02 14:04:11 -0700)
>
> are available in the Git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git tags/bpf-next-7.4
>
> for you to fetch changes up to b116ac6087541d3d98031e786adbe9c733cd6df3:
>
>   selftests/bpf: Time tc_edt from its first packet with data (2026-10-21 17:50:51 +0000)

...

> Other features and fixes:
>
> - Let BPF LSM set xattrs at inode creation with bpf_inode_init_xattr()
>   (David Windsor, Daniel Borkmann)

I need to object to the BPF LSM kfunc added in commit ff0d1c0915d1
("bpf, lsm: Let BPF LSM provide xattrs at inode creation") for reasons
already mentioned in the thread below:

https://lore.kernel.org/all/20260915150739.284189-5-daniel@iogearbox.net

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.  The bpf_inode_init_xattr() kfunc is called
from a BPF LSM program where it allocates a buffer for an xattr
name/value pairing, updates the LSM framework managed list with the
name/value pair, and then returns to the BPF LSM program which in turn
returns to the LSM framework where security_inode_init_security()
writes the inode's xattrs collected from all of the enabled LSMs.  The
bpf_inode_init_xattr() kfunc does not call into any VFS APIs, but it
does call into an LSM internal API.  There is no good technical reason
why this kfunc is located outside the security/ directory, and given
that there is plenty of precdence for BPF kfuncs located outside of
bpf/ (e.g. drivers, VFS, io_uring, cgroups, scheduler, mm, networking,
etc.) 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:

https://lore.kernel.org/linux-security-module/DLD0VQ3D8CYC.3V5ZT8HDMY4IH@gmail.com

I'm supportive of the work that David Windsor did to enable BPF LSMs
to leverage the security_inode_init_security() LSM hook, and generally
speaking I'm supportive of changes to make it easier for BPF LSM
developers to use existing LSM hooks (there were multiple changes in
the Linux v7.4 LSM framework pull request to do just that), but I
can't support the BPF maintainers actively circumventing
review/oversight from LSM developers.  I'm happy to support David's
work, but the bpf_inode_init_xattr() kfunc, and associacted code,
needs to be moved into security/bpf_lsm_kfuncs.c.

-- 
paul-moore.com