Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Tue, Sep 15, 2026 at 11:07 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> From: David Windsor <dwindsor@gmail.com>
>
> Many in-kernel LSMs (SELinux, Smack, IMA) store security labels in extended
> attributes. For these LSMs, atomic labeling during inode creation is
> critical: if the inode becomes accessible before its xattr is set, it is
> briefly unlabeled, which can disrupt LSMs making policy decisions based
> on file labels. Existing LSMs solve this by setting xattrs in the
> inode_init_security hook, which runs before the inode becomes accessible.
> BPF LSM programs currently lack this capability because the hook uses an
> output parameter (xattr_count) that BPF programs cannot write to, and
> existing kfuncs like bpf_set_dentry_xattr() require a dentry that isn't
> available until after the inode is accessible.
>
> Add a bpf_inode_init_xattr() kfunc that takes the hook's own xattrs and
> xattr_count arguments, passed through from the program's context, and
> claims a slot via lsm_get_xattr_slot() on the program's behalf. The
> xattr_count output argument is exposed to inode_init_security programs
> as trusted read-only memory, so programs can pass it to the kfunc but
> cannot modify the count themselves.
>
> Reserve BPF_LSM_INODE_INIT_XATTRS slots in bpf_lsm_blob_sizes the way
> every other xattr-providing LSM does, for the life of the kernel. The
> framework keys the collection off the reserved slot count, so a kernel
> built with CONFIG_BPF_LSM=y now allocates the xattr array on every inode
> creation, whether or not a program sits on the hook.
>
> Give the hook a strong prototype in bpf_lsm_proto.c so that its qstr and
> xattrs arguments are marked __nullable. Both can be NULL for some callers.
> Without the annotation the verifier otherwise hands the program a trusted
> non-NULL pointer which it dereferences. Also, keep the hook out of the
> sleepable set. inode_init_security runs inside the transaction creating
> the inode, with a journal handle held on ext4 and btrfs and the parent's
> i_rwsem down, which is why everything on the path allocates GFP_NOFS.
>
> Signed-off-by: David Windsor <dwindsor@gmail.com>
> Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
>  fs/bpf_fs_kfuncs.c         | 99 ++++++++++++++++++++++++++++++++++++++
>  include/linux/bpf_lsm.h    | 11 ++++-
>  kernel/bpf/bpf_lsm.c       | 22 ++++++++-
>  kernel/bpf/bpf_lsm_proto.c | 15 ++++++
>  security/bpf/hooks.c       |  1 +
>  5 files changed, 145 insertions(+), 3 deletions(-)

@Daniel, you were CC'd on David's previous patches, so I'm guessing
you saw my objection[1], but just in case you hadn't please look at my
comments where I requested that David's proposed LSM kfunc be located
in security/bpf_lsm_kfuncs.c as opposed to fs/bpf_fs_kfuncs.c.  It
would be really nice if we could sort this out now and avoid having
this drag out or escalate.

@David, simply for my own understanding, did you ask Daniel to do
this, or was Daniel operating on his own with this patchset?

[1] https://lore.kernel.org/linux-security-module/CAHC9VhTS7rSnBqg00ZxNkcZyh_=EeJmn_4z3CTCCxreEEDtTtg@mail.gmail.com/

-- 
paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Daniel Borkmann]

On 9/23/26 6:57 PM, Paul Moore wrote:
> On Tue, Sep 15, 2026 at 11:07 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> From: David Windsor <dwindsor@gmail.com>
>>
>> Many in-kernel LSMs (SELinux, Smack, IMA) store security labels in extended
>> attributes. For these LSMs, atomic labeling during inode creation is
>> critical: if the inode becomes accessible before its xattr is set, it is
>> briefly unlabeled, which can disrupt LSMs making policy decisions based
>> on file labels. Existing LSMs solve this by setting xattrs in the
>> inode_init_security hook, which runs before the inode becomes accessible.
>> BPF LSM programs currently lack this capability because the hook uses an
>> output parameter (xattr_count) that BPF programs cannot write to, and
>> existing kfuncs like bpf_set_dentry_xattr() require a dentry that isn't
>> available until after the inode is accessible.
>>
>> Add a bpf_inode_init_xattr() kfunc that takes the hook's own xattrs and
>> xattr_count arguments, passed through from the program's context, and
>> claims a slot via lsm_get_xattr_slot() on the program's behalf. The
>> xattr_count output argument is exposed to inode_init_security programs
>> as trusted read-only memory, so programs can pass it to the kfunc but
>> cannot modify the count themselves.
>>
>> Reserve BPF_LSM_INODE_INIT_XATTRS slots in bpf_lsm_blob_sizes the way
>> every other xattr-providing LSM does, for the life of the kernel. The
>> framework keys the collection off the reserved slot count, so a kernel
>> built with CONFIG_BPF_LSM=y now allocates the xattr array on every inode
>> creation, whether or not a program sits on the hook.
>>
>> Give the hook a strong prototype in bpf_lsm_proto.c so that its qstr and
>> xattrs arguments are marked __nullable. Both can be NULL for some callers.
>> Without the annotation the verifier otherwise hands the program a trusted
>> non-NULL pointer which it dereferences. Also, keep the hook out of the
>> sleepable set. inode_init_security runs inside the transaction creating
>> the inode, with a journal handle held on ext4 and btrfs and the parent's
>> i_rwsem down, which is why everything on the path allocates GFP_NOFS.
>>
>> Signed-off-by: David Windsor <dwindsor@gmail.com>
>> Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>>   fs/bpf_fs_kfuncs.c         | 99 ++++++++++++++++++++++++++++++++++++++
>>   include/linux/bpf_lsm.h    | 11 ++++-
>>   kernel/bpf/bpf_lsm.c       | 22 ++++++++-
>>   kernel/bpf/bpf_lsm_proto.c | 15 ++++++
>>   security/bpf/hooks.c       |  1 +
>>   5 files changed, 145 insertions(+), 3 deletions(-)
> 
> @Daniel, you were CC'd on David's previous patches, so I'm guessing
> you saw my objection[1], but just in case you hadn't please look at my
> comments where I requested that David's proposed LSM kfunc be located
> in security/bpf_lsm_kfuncs.c as opposed to fs/bpf_fs_kfuncs.c.  It
> would be really nice if we could sort this out now and avoid having
> this drag out or escalate.

Paul, I reached out to David recently asking whether I could offer some
help with the BPF bits, added some bug fixes and a lot more BPF selftests
as I think the inode xattr init is valuable work and something we need as
well. I just reread this whole thread below given its quite a while back
and didn't follow in too much detail back then.. the location as it is is
perfectly fine, I see no reason to change it, and I guess that makes three
of us then including the VFS folks [0]. In that file there are a number of
other kfuncs as well already related to xattr in context of dentry, files,
etc. I don't see a point at all on endless bike shedding on this, its
perfectly reasonably where this is located. In case you have some technical
comment or found a bug, let me know, happy to address.

   [0] https://lore.kernel.org/bpf/20260625-schnabel-rennmaschine-parieren-bcb352c3cf59@brauner/

> @David, simply for my own understanding, did you ask Daniel to do
> this, or was Daniel operating on his own with this patchset?
> 
> [1] https://lore.kernel.org/linux-security-module/CAHC9VhTS7rSnBqg00ZxNkcZyh_=EeJmn_4z3CTCCxreEEDtTtg@mail.gmail.com/
> 

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Wed, Sep 23, 2026 at 3:11 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 9/23/26 6:57 PM, Paul Moore wrote:
> > On Tue, Sep 15, 2026 at 11:07 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >> From: David Windsor <dwindsor@gmail.com>
> >>
> >> Many in-kernel LSMs (SELinux, Smack, IMA) store security labels in extended
> >> attributes. For these LSMs, atomic labeling during inode creation is
> >> critical: if the inode becomes accessible before its xattr is set, it is
> >> briefly unlabeled, which can disrupt LSMs making policy decisions based
> >> on file labels. Existing LSMs solve this by setting xattrs in the
> >> inode_init_security hook, which runs before the inode becomes accessible.
> >> BPF LSM programs currently lack this capability because the hook uses an
> >> output parameter (xattr_count) that BPF programs cannot write to, and
> >> existing kfuncs like bpf_set_dentry_xattr() require a dentry that isn't
> >> available until after the inode is accessible.
> >>
> >> Add a bpf_inode_init_xattr() kfunc that takes the hook's own xattrs and
> >> xattr_count arguments, passed through from the program's context, and
> >> claims a slot via lsm_get_xattr_slot() on the program's behalf. The
> >> xattr_count output argument is exposed to inode_init_security programs
> >> as trusted read-only memory, so programs can pass it to the kfunc but
> >> cannot modify the count themselves.
> >>
> >> Reserve BPF_LSM_INODE_INIT_XATTRS slots in bpf_lsm_blob_sizes the way
> >> every other xattr-providing LSM does, for the life of the kernel. The
> >> framework keys the collection off the reserved slot count, so a kernel
> >> built with CONFIG_BPF_LSM=y now allocates the xattr array on every inode
> >> creation, whether or not a program sits on the hook.
> >>
> >> Give the hook a strong prototype in bpf_lsm_proto.c so that its qstr and
> >> xattrs arguments are marked __nullable. Both can be NULL for some callers.
> >> Without the annotation the verifier otherwise hands the program a trusted
> >> non-NULL pointer which it dereferences. Also, keep the hook out of the
> >> sleepable set. inode_init_security runs inside the transaction creating
> >> the inode, with a journal handle held on ext4 and btrfs and the parent's
> >> i_rwsem down, which is why everything on the path allocates GFP_NOFS.
> >>
> >> Signed-off-by: David Windsor <dwindsor@gmail.com>
> >> Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
> >> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> >> ---
> >>   fs/bpf_fs_kfuncs.c         | 99 ++++++++++++++++++++++++++++++++++++++
> >>   include/linux/bpf_lsm.h    | 11 ++++-
> >>   kernel/bpf/bpf_lsm.c       | 22 ++++++++-
> >>   kernel/bpf/bpf_lsm_proto.c | 15 ++++++
> >>   security/bpf/hooks.c       |  1 +
> >>   5 files changed, 145 insertions(+), 3 deletions(-)
> >
> > @Daniel, you were CC'd on David's previous patches, so I'm guessing
> > you saw my objection[1], but just in case you hadn't please look at my
> > comments where I requested that David's proposed LSM kfunc be located
> > in security/bpf_lsm_kfuncs.c as opposed to fs/bpf_fs_kfuncs.c.  It
> > would be really nice if we could sort this out now and avoid having
> > this drag out or escalate.
>
> Paul, I reached out to David recently asking whether I could offer some
> help with the BPF bits, added some bug fixes and a lot more BPF selftests
> as I think the inode xattr init is valuable work and something we need as
> well. I just reread this whole thread below given its quite a while back
> and didn't follow in too much detail back then.. the location as it is is
> perfectly fine, I see no reason to change it, and I guess that makes three
> of us then including the VFS folks [0].

I didn't think there were any doubts that the BPF and VFS folks wanted
the kfunc in fs/bpf_fs_kfuncs.c, but I thought I made my objections
clear in the previous revisions.  While you've changed things slightly
from David's last patchset, essentially folding the proposed
security_lsmxattr_add() helper into the bpf_inode_init_xattr(), it
does appear that the basic purpose and context around the kfunc
remains the same: the proposed kfunc is called from a LSM
inode_init_security callback, it populates a LSM framework managed
buffer, and then when the LSM callback returns the LSM framework code
in security_inode_init_security() does the xattr init based on the
buffers populated by all of the configured LSMs (the BPF LSM as well
as others).  As there are no direct calls to the VFS layer in the
kfunc, but there are direct calls into LSM internal APIs (e.g.
lsm_get_xattr_slot(), as well as the LSM state and calling context
mentioned above, from my perspective this really does need to be
located in a LSM framework BPF kfunc file (e.g.
security/bpf_lsm_kfuncs.c).  I've mentioned several times in David's
previous postings that I'm happy to work with you and the BPF devs to
set that up.  If you are open to that let's sort it out now so we can
get everything in place before the merge window.  If that isn't
something you are able to do, that would also be good to know.

-- 
paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[David Windsor]

On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> @David, simply for my own understanding, did you ask Daniel to do
> this, or was Daniel operating on his own with this patchset?
>

Daniel and I work together and both have things written on top of this
kfunc. He reached out to collaborate, I agreed. We're also going to
send bpf_set_file_xattr shortly.

This implementation was chosen due to its immediate mergeability (it
only touches security/bpf), but was actually suggested by Kumar in v1
or so of my original series.

That said, sorry for any confusion about this appearing as a new
series rather than as v7 of my previous one.

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Wed, Sep 23, 2026 at 3:14 PM David Windsor <dwindsor@gmail.com> wrote:
> On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> > @David, simply for my own understanding, did you ask Daniel to do
> > this, or was Daniel operating on his own with this patchset?
> >
>
> Daniel and I work together and both have things written on top of this
> kfunc. He reached out to collaborate, I agreed. We're also going to
> send bpf_set_file_xattr shortly.
>
> This implementation was chosen due to its immediate mergeability (it
> only touches security/bpf), but was actually suggested by Kumar in v1
> or so of my original series.
>
> That said, sorry for any confusion about this appearing as a new
> series rather than as v7 of my previous one.

Thanks for your perspective.

To be perfectly honest with you, seeing this patchset land in
linux-next without it being posted to the LSM list, or at least CC'ing
me, after all the discussions on the previous iterations seemed a bit
suspect, especially considering the rather rocky relations between the
BPF and LSM communities at the moment.  Regardless, hopefully we can
get this sorted out.

-- 
paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Wed, Sep 23, 2026 at 3:14 PM David Windsor <dwindsor@gmail.com> wrote:
>
> This implementation was chosen due to its immediate mergeability (it
> only touches security/bpf) ...

Ooops, I hit send on my reply to you too soon.

It's worth mentioning that sometimes maintainer objections/NACKs can
cross subsystem boundaries.  You may not have followed it, but a while
ago a LSM was proposed that implemented BPF program load access
controls and it was successfully NACK'd by the BPF devs, despite it
not touching any BPF code.  An argument was made that the proposed LSM
manipulated internal BPF state (there were arguments on both sides of
that topic), similar to what the proposed BPF kfunc is doing with the
LSM framework.

Hopefully we won't have a repeat situation here, but it is worth
knowing that code location alone doesn't necessarily equate to
"immediate mergeability" based on recent history.

-- 
paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Justin Suess]

On Wed, Sep 23, 2026 at 03:14:28PM -0400, David Windsor wrote:
> On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> > @David, simply for my own understanding, did you ask Daniel to do
> > this, or was Daniel operating on his own with this patchset?
> >
> 
> Daniel and I work together and both have things written on top of this
> kfunc. He reached out to collaborate, I agreed. We're also going to
> send bpf_set_file_xattr shortly.
> 
> This implementation was chosen due to its immediate mergeability (it
> only touches security/bpf), but was actually suggested by Kumar in v1
> or so of my original series.
> 
> That said, sorry for any confusion about this appearing as a new
> series rather than as v7 of my previous one.
>
Howdy all,

Hope you all are doing well and having a good Thursday.

These patches are excellent and useful, and have been in the pipeline
for a while. 

In the interest of moving forward:

Would you both be able to live with the following: provide a security hook
for lsm_get_xattr_slot or another proper interface with the necessary
abstraction, and keep the kfunc where it is in fs/?

This addresses the primary concern about calling into LSM internals by
providing a blessed interface. I'd be happy to detail what I had in mind.

I think the end users care extremely little about what directory the
source code ends up in. They care about: getting useful features.

We all work in the same kernel and it's easier to walk when both legs
are going in the same direction. I think that this hill would be an
unfitting, uninteresting place for these useful patches to die on :) 

Let me know if this is something you both could stomach.

Sincerely,
Justin

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Thu, Sep 24, 2026 at 12:15 PM Justin Suess <utilityemal77@gmail.com> wrote:
> On Wed, Sep 23, 2026 at 03:14:28PM -0400, David Windsor wrote:
> > On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> > > @David, simply for my own understanding, did you ask Daniel to do
> > > this, or was Daniel operating on his own with this patchset?
> > >
> >
> > Daniel and I work together and both have things written on top of this
> > kfunc. He reached out to collaborate, I agreed. We're also going to
> > send bpf_set_file_xattr shortly.
> >
> > This implementation was chosen due to its immediate mergeability (it
> > only touches security/bpf), but was actually suggested by Kumar in v1
> > or so of my original series.
> >
> > That said, sorry for any confusion about this appearing as a new
> > series rather than as v7 of my previous one.
>
> Howdy all,
>
> Hope you all are doing well and having a good Thursday.
>
> These patches are excellent and useful, and have been in the pipeline
> for a while.
>
> In the interest of moving forward:
>
> Would you both be able to live with the following: provide a security hook
> for lsm_get_xattr_slot or another proper interface with the necessary
> abstraction, and keep the kfunc where it is in fs/?

That still doesn't change the fundamentals around the kfunc: it is
really only a valid to call it from within the LSM inode_init_security
callback, it populates a LSM framework managed buffer, and that buffer
is then used to by the LSM framework code in
security_inode_init_security() to do the xattr initialization using
the values from the BPF LSM as well as all of the other configured
LSMs.  It's very hard to see this as anything other than an LSM kfunc.
I worked with David over several revisions of his patchset to review
the code and get it in a good place, I'm supportive of the basic
ideas, but this really needs to be located in
security/bpf_lsm_kfuncs.c as it is an LSM kfunc.  As we've seen there
is precedence for subsystem specific kfuncs located in the associated
subsystem's directory, things should be no different here.

-- 
paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Justin Suess]

On Thu, Sep 24, 2026 at 12:23:13PM -0400, Paul Moore wrote:
> On Thu, Sep 24, 2026 at 12:15 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Wed, Sep 23, 2026 at 03:14:28PM -0400, David Windsor wrote:
> > > On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > @David, simply for my own understanding, did you ask Daniel to do
> > > > this, or was Daniel operating on his own with this patchset?
> > > >
> > >
> > > Daniel and I work together and both have things written on top of this
> > > kfunc. He reached out to collaborate, I agreed. We're also going to
> > > send bpf_set_file_xattr shortly.
> > >
> > > This implementation was chosen due to its immediate mergeability (it
> > > only touches security/bpf), but was actually suggested by Kumar in v1
> > > or so of my original series.
> > >
> > > That said, sorry for any confusion about this appearing as a new
> > > series rather than as v7 of my previous one.
> >
> > Howdy all,
> >
> > Hope you all are doing well and having a good Thursday.
> >
> > These patches are excellent and useful, and have been in the pipeline
> > for a while.
> >
> > In the interest of moving forward:
> >
> > Would you both be able to live with the following: provide a security hook
> > for lsm_get_xattr_slot or another proper interface with the necessary
> > abstraction, and keep the kfunc where it is in fs/?
> 
> That still doesn't change the fundamentals around the kfunc: it is
> really only a valid to call it from within the LSM inode_init_security
> callback, it populates a LSM framework managed buffer, and that buffer
> is then used to by the LSM framework code in
> security_inode_init_security() to do the xattr initialization using
> the values from the BPF LSM as well as all of the other configured
> LSMs.  It's very hard to see this as anything other than an LSM kfunc.
> I worked with David over several revisions of his patchset to review
> the code and get it in a good place, I'm supportive of the basic
> ideas, but this really needs to be located in
> security/bpf_lsm_kfuncs.c as it is an LSM kfunc.  As we've seen there
> is precedence for subsystem specific kfuncs located in the associated
> subsystem's directory, things should be no different here.
>
Hello,

I'm less arguing for any particular placement:

More so that the concrete security interest of just getting the kfunc
*somewhere* is much more important. I have no doubt that the function
would be equally well stewarded in either directory.

The xattr kfunc in security/ question can be fought best in a different
venue where it's not holding back good contributions. So I think
swallowing this bitter pill for now will be best for cooperation and
good faith if nothing else, otherwise users and contributors are left
footing the bill indefinitely.

Admittedly I'm biased and am toying with a project that this kfunc
would be really nice in, so take me with a grain of salt :)

Thanks,
Justin

> -- 
> paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Thu, Sep 24, 2026 at 2:38 PM Justin Suess <utilityemal77@gmail.com> wrote:
> On Thu, Sep 24, 2026 at 12:23:13PM -0400, Paul Moore wrote:
> > On Thu, Sep 24, 2026 at 12:15 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > > On Wed, Sep 23, 2026 at 03:14:28PM -0400, David Windsor wrote:
> > > > On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > @David, simply for my own understanding, did you ask Daniel to do
> > > > > this, or was Daniel operating on his own with this patchset?
> > > > >
> > > >
> > > > Daniel and I work together and both have things written on top of this
> > > > kfunc. He reached out to collaborate, I agreed. We're also going to
> > > > send bpf_set_file_xattr shortly.
> > > >
> > > > This implementation was chosen due to its immediate mergeability (it
> > > > only touches security/bpf), but was actually suggested by Kumar in v1
> > > > or so of my original series.
> > > >
> > > > That said, sorry for any confusion about this appearing as a new
> > > > series rather than as v7 of my previous one.
> > >
> > > Howdy all,
> > >
> > > Hope you all are doing well and having a good Thursday.
> > >
> > > These patches are excellent and useful, and have been in the pipeline
> > > for a while.
> > >
> > > In the interest of moving forward:
> > >
> > > Would you both be able to live with the following: provide a security hook
> > > for lsm_get_xattr_slot or another proper interface with the necessary
> > > abstraction, and keep the kfunc where it is in fs/?
> >
> > That still doesn't change the fundamentals around the kfunc: it is
> > really only a valid to call it from within the LSM inode_init_security
> > callback, it populates a LSM framework managed buffer, and that buffer
> > is then used to by the LSM framework code in
> > security_inode_init_security() to do the xattr initialization using
> > the values from the BPF LSM as well as all of the other configured
> > LSMs.  It's very hard to see this as anything other than an LSM kfunc.
> > I worked with David over several revisions of his patchset to review
> > the code and get it in a good place, I'm supportive of the basic
> > ideas, but this really needs to be located in
> > security/bpf_lsm_kfuncs.c as it is an LSM kfunc.  As we've seen there
> > is precedence for subsystem specific kfuncs located in the associated
> > subsystem's directory, things should be no different here.
> >
> Hello,
>
> I'm less arguing for any particular placement:
>
> More so that the concrete security interest of just getting the kfunc
> *somewhere* is much more important. I have no doubt that the function
> would be equally well stewarded in either directory.
>
> The xattr kfunc in security/ question can be fought best in a different
> venue where it's not holding back good contributions.

This (the mailing list) is *the* venue, and sorting out
cross-subsystem issues isn't a foundational thing, not something that
can be cast aside because it is inconvenient.  In this particular
case, resolving this before it lands in Linus' tree is that much more
important since cooperation has been "strained" to put it mildly.

-- 
paul-moore.com

Re: [PATCH bpf-next 4/8] bpf, lsm: Let BPF LSM provide xattrs at inode creation

[Paul Moore]

On Thu, Sep 24, 2026 at 3:33 PM Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Sep 24, 2026 at 2:38 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > On Thu, Sep 24, 2026 at 12:23:13PM -0400, Paul Moore wrote:
> > > On Thu, Sep 24, 2026 at 12:15 PM Justin Suess <utilityemal77@gmail.com> wrote:
> > > > On Wed, Sep 23, 2026 at 03:14:28PM -0400, David Windsor wrote:
> > > > > On Wed, Sep 23, 2026 at 12:57 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > > @David, simply for my own understanding, did you ask Daniel to do
> > > > > > this, or was Daniel operating on his own with this patchset?
> > > > > >
> > > > >
> > > > > Daniel and I work together and both have things written on top of this
> > > > > kfunc. He reached out to collaborate, I agreed. We're also going to
> > > > > send bpf_set_file_xattr shortly.
> > > > >
> > > > > This implementation was chosen due to its immediate mergeability (it
> > > > > only touches security/bpf), but was actually suggested by Kumar in v1
> > > > > or so of my original series.
> > > > >
> > > > > That said, sorry for any confusion about this appearing as a new
> > > > > series rather than as v7 of my previous one.
> > > >
> > > > Howdy all,
> > > >
> > > > Hope you all are doing well and having a good Thursday.
> > > >
> > > > These patches are excellent and useful, and have been in the pipeline
> > > > for a while.
> > > >
> > > > In the interest of moving forward:
> > > >
> > > > Would you both be able to live with the following: provide a security hook
> > > > for lsm_get_xattr_slot or another proper interface with the necessary
> > > > abstraction, and keep the kfunc where it is in fs/?
> > >
> > > That still doesn't change the fundamentals around the kfunc: it is
> > > really only a valid to call it from within the LSM inode_init_security
> > > callback, it populates a LSM framework managed buffer, and that buffer
> > > is then used to by the LSM framework code in
> > > security_inode_init_security() to do the xattr initialization using
> > > the values from the BPF LSM as well as all of the other configured
> > > LSMs.  It's very hard to see this as anything other than an LSM kfunc.
> > > I worked with David over several revisions of his patchset to review
> > > the code and get it in a good place, I'm supportive of the basic
> > > ideas, but this really needs to be located in
> > > security/bpf_lsm_kfuncs.c as it is an LSM kfunc.  As we've seen there
> > > is precedence for subsystem specific kfuncs located in the associated
> > > subsystem's directory, things should be no different here.
> > >
> > Hello,
> >
> > I'm less arguing for any particular placement:
> >
> > More so that the concrete security interest of just getting the kfunc
> > *somewhere* is much more important. I have no doubt that the function
> > would be equally well stewarded in either directory.
> >
> > The xattr kfunc in security/ question can be fought best in a different
> > venue where it's not holding back good contributions.
>
> This (the mailing list) is *the* venue, and sorting out
> cross-subsystem issues isn't a foundational thing, not something that

Sorry, typo.

/isn't/is/

Sorting out cross-subsystem issues *is* a foundational thing.

> can be cast aside because it is inconvenient.  In this particular
> case, resolving this before it lands in Linus' tree is that much more
> important since cooperation has been "strained" to put it mildly.

-- 
paul-moore.com