[GIT PULL] BPF changes for 7.4

[Paul Moore]

On Wed, Oct 21, 2026 at 6:45 PM Alexei Starovoitov
<alexei.starovoitov at gmail.com> wrote:
> On Wed, Oct 21, 2026 at 02:26 PM Paul Moore <paul at 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

Exactly.  It's not a new ask and I'll be happy to create it and move
the kfunc if doing the work is your only objection ;)

> ... 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/

"... just as the maintenence of bpf_fs_funcs.c falls to the VFS." is
the rest of that sentence.  We're not asking for a type of
cross-subsystem relationship without precedent.

> 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/

As discussed previously, the kfunc in question isn't really a VFS
kfunc it's a LSM kfunc populating LSM managed buffers and calling into
LSM private APIs.

One might question the placement of some of the other BPF kfuncs
located in bpf_fs_kfuncs.c as the file is conditionally built based on
CONFIG_BPF_LSM as opposed to CONFIG_BPF_SYSCALL or some other generic
BPF Kconfig knob, but there is no sense in worrying about that until
we settle this.

> > 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.

Yes, that is what I meant when I said it was calling an internal LSM
API.  The lsm_get_xattr_slot() function is intended for use by LSMs
(it's not an external LSM "hook") and the fact that the kfunc in
question calls into it (and not a single VFS function) is one of the
reasons why I'm arguing strongly that this is purely a LSM kfunc and
should be located in security/bpf_lsm_funcs.c.

> > 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."

It's worth reading the discussions from all of David's patches, but
for those who don't have the time, I would at least read how I ended
the email Alexei references:

"I've been working with David and providing feedback for a while now
(perhaps before you started commenting? not sure on that), and I'm
continuing to engage with David, you, and anyone else who wants to
comment on this thread."

> > 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 isn't just about CC'ing the proper lists, although that is an
important first step.  It's about actually being open to feedback and
working with other subsystems to arrive at a solution that everyone
can accept, even if they do so begrudgingly.  Forcing something
through like this against the wishes of other subsystems is a last
resort and needs to be called out in the pull request so Linus is made
aware of it and can arbitrate as he deems necessary.  You can draw
parallels to the Hornet LSM debacle, and while we never got to the
point of sending a pull request to Linus, we definitely made you aware
of the work and believe it or not, we did incorporate your feedback
and tried to work with you as much as was humanly possible.

(As an aside, for those who only casually followed the BPF signing
developments of the past several years, it is worth noting that
shortly after Hornet was rejected, Daniel proposed a solution eerily
similar to something that Blase had previously proposed and which the
BPF devs had rejected.  Despite the odd about-face after all the
mudslinging, we did continue to work with Daniel on his new/old
patchset because we genuinely do want to see the right things happen
in the kernel.)

https://lore.kernel.org/bpf/CAHC9VhTA7tOp16wGzb1QYnkJsVz1X3oNcmT6bb_9334=B2smEw@mail.gmail.com

-- 
paul-moore.com