Re: [GIT PULL] BPF changes for 7.4

Re: [GIT PULL] BPF changes for 7.4

[Paul Moore]

On Wed, Oct 21, 2026 at 5:01 PM Alexei Starovoitov
<alexei.starovoitov@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

Re: [GIT PULL] BPF changes for 7.4

[Alexei Starovoitov]

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.

Re: [GIT PULL] BPF changes for 7.4

[Paul Moore]

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

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

Re: [GIT PULL] BPF changes for 7.4

[Alexei Starovoitov]

On Wed, Oct 21, 2026 at 06:26 PM Paul Moore <paul@paul-moore.com> wrote:
>
> "... 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.

That file has a history.

Nov 2023. Song added bpf_get_file_xattr() for BPF LSM progs to
kernel/trace/bpf_trace.c:
commit ac9c05e0e453 ("bpf: Add kfunc bpf_get_file_xattr")

Mar 2024. Matt's v2 was adding more kfuncs for BPF LSM progs next to it.
Christian replied:
"Conditio sine qua non is that all such kfunc definitions must live in
the respective file in fs/. They won't be hidden somewhere in
kernel/bpf/."
https://lore.kernel.org/bpf/20240306-zeitumstellung-darben-7857ca9817c0@brauner/

Jul 2024. After discussions with Christian at LSFMMBPF Matt created
fs/bpf_fs_kfuncs.c in v3:
commit d08e2045ebf0 ("bpf: introduce new VFS based BPF kfuncs")
Christian acked it and asked for more:
"I also wouldn't mind follow-up patches that move the xattr bpf kfuncs
under fs/ as well."
https://lore.kernel.org/bpf/20240726-clown-geantwortet-eb29a17890c3@brauner/

Aug 2024. Song moved bpf_get_file_xattr() there:
commit fa4e5afa9758 ("bpf: Move bpf_get_file_xattr to fs/bpf_fs_kfuncs.c")
"We are putting all fs kfuncs in fs/bpf_fs_kfuncs.c."

Every xattr kfunc since then went there: bpf_get_dentry_xattr(),
bpf_{set,remove}_dentry_xattr(), bpf_cgroup_read_xattr() from Song,
bpf_sock_read_xattr() from Christian.
David's v1 in April put the new one next to them.
It cannot be in fs/ and in security/ at the same time.

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

Back in 2024 all kfuncs in that file were for BPF LSM progs. Matt's v2
from Mar 2024 even called the set lsm_kfunc_set_ids. They moved to fs/
anyway. Hence CONFIG_BPF_LSM.

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

BPF LSM is in kernel/bpf/bpf_lsm.c since 2020 and includes lsm_hooks.h
since then. bpf_bprm_opts_set(), bpf_ima_inode_hash(), bpf_ima_file_hash()
helpers that only BPF LSM progs can call are there too.
security/bpf/hooks.c is 43 lines that register it.

I don't feel we will converge here.

Linus,
it's your call. If you think the kfunc should move I'll send a follow up.
bpf progs don't see which file a kfunc is in, so there is no need to
hold the pull request for that.
imo xattrs are VFS territory.

Re: [GIT PULL] BPF changes for 7.4

[Christian Brauner]

On Wed, Oct 21, 2026 at 09:26:56PM -0400, Paul Moore wrote:
> "... 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.

I love how I always end up in the middle of this somehow. I'm really
trying to be sympathetic to both sides.

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

It takes a name in the security.bpf. namespace checks it against
XATTR_NAME_MAX and XATTR_SIZE_MAX, copies the value and fills a struct
xattr that the filesystem's ->initxattrs() callback writes into the
inode it is in the middle of creating.

The LSM part is lsm_get_xattr_slot(), a static inline that hands out the
next entry of an array.

The one problem the series ran into was ocfs2 keeping the name pointer
around after the callback. Which is very much a filesystem contract and
it got sorted out with the ocfs2 maintainers. This is a decent hint
where this code belongs imho.

> 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 CONFIG_BPF_LSM gate is historical. binfmt_misc BPF programs use
the file as well. It says nothing about who owns the file though.

My view is this:

The lsm framework doesn't own code in other subsystems because it calls
an lsm helper. The same way the vfs doesn't own the lsms simply because
the majority of them live on vfs objects.

I do understand the worry I guess. bpf lsm programs let people build
policy that never shows up on the Lsm list, and kfuncs are ways to build
that policy. For me that's a good thing because it moves a bunch of code
out of the kernel. I understand that it's also something that feels
uncomfortable. It does for me too because I keep worrying "what if we
expose some really broken thing that burns the house down"? But hey, 50%
of kernel development is constant change and 50% is shepherding people
away from the abyss...

--