Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling

On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Kartikeya Dwivedi
<[email protected]> wrote:
> On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wrote:
> > On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Kartikeya Dwivedi
> > <[email protected]> wrote:
> >> On Fri Jul 31, 2026 at 5:30 PM CEST, David Windsor wrote:
> >> > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore <paul@paul-moore=
.com> wrote:
> >> >>
> >> >>
> >> >> Okay, it looks like there was some confusion/misunderstanding.
> >> >>
> >> >> My understanding of Kumar's comments was that he was referring to t=
he
> >> >> exisiting LSM related kfuncs that are located in fs/bpf_fs_kfuncs.c=
,
> >> >> not necessarily the new kfunc you are proposing in this patchset.
> >> >> Kumar is welcome to correct either one or both of us, if we read th=
at
> >> >> wrong :)
> >> >>
> >> >
> >> > Yes, after another reading, that does appear to be the case =3D).
> >> >
> >> > We'll need v7 anyway to fix the ocfs-related UAF the bot found.
> >> >
> >>
> >> Since there is confusion, let me clear it up.
> >>
> >> I meant it for all of them. I don't think it makes sense to keep this =
one in
> >> security/ when others are in fs/bpf_fs_kfuncs.c. That confusing limbo =
state is
> >> worse than just placing it where others already are.
> >>
> >> As I already said, the discussion around whether all of them they shou=
ld go in
> >> security/ is orthogonal and should be done separately; it isn't produc=
tive to
> >> repeatedly bring it up in the context of this patch set.
> >>
> >> I honestly don't get the urgency; it will be a mechanical change if we=
 need to
> >> make such changes. The worst outcome would be stalling David's work ov=
er it.
> >>
> >> As for landing this stuff, we can let Paul take the patches touching s=
ecurity/
> >> and route the rest (3-4) through bpf-next after the merge window. We n=
eed them
> >> to go through BPF CI anyway to ensure nothing breaks.
> >
> > Some existing LSM kfuncs are located in the wrong files.  I'm not
> > suggesting that David needs to fix the existing problems, but there is
> > no reason to keep making the same mistakes.  The new LSM kfunc must go
> > in security/bpf_lsm_kfuncs.c; if that isn't acceptable to the BPF
> > developers then David will need to find a new way that doesn't involve
> > kfuncs.
>
> What "mistakes"? Really? It's just code organization bureaucracy. Calling=
 it a
> mistake is just blowing things out of proportion.

 :D

You've no doubt seen the challenging interactions between some of the
BPF and LSM developers over the past several years.  A recent BPF LSM
bug/vulnerability as well as these interactions between the BPF/LSM
devs, has caused me to take a much closer look at how things have been
done regarding the BPF LSM and there are a number of things that
should be addressed.  Not all of those things will be addressed now,
but I won't support patches that continue to do things the wrong way
because I currently have very little faith in our ability to correct
them later.  I do hope that at some time in the future we can reach a
point where there is more cooperation between the two communities, but
given the recent difficulties over even the small things, we are not
there yet.

> I don't think you can simply decide this unilaterally either. Do you take=
 full
> responsibility that kfuncs going there won't introduce BPF side regressio=
ns? Who
> makes sure patches touching the new location run through BPF CI? All of t=
his
> needs to be thought through before we decide upon anything.

I would expect, and require, that patch submitters perform the
necessary testing for the patches they submit; this is no different
from any other patch today that is submitted for the LSM framework.
Patch submitters would also be required to CC the BPF mailing list and
I would encourage interested BPF community members to offer their
feedback and review; once again, this is no different from any other
cross-subsystem patch today submitted for the LSM framework.

> Thus, I am simply asking you to be reasonable: let's help David make prog=
ress,
> and get the changes landed. FS, BPF, and LSM folks can then decide on whe=
re to
> copy paste the existing kfuncs later.

I view my position as both entirely reasonable and consistent with the
current LSM approach to cross-subsystem patches.  The location of the
kfunc David is proposing is dictated largely by the kfunc's contents
and interactions; it is only legal to be called from an LSM hook
callback, it manipulates LSM-only data structures, and aside from some
BPF kfunc boilerplate, it only calls into LSM hooks/functions.

--=20
paul-moore.com