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@xxxxxxxxx> 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@xxxxxxxxxxxxxx> 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