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

On Sat Aug 1, 2026 at 1:34 AM CEST, Kumar Kartikeya Dwivedi wrote:
> On Sat Aug 1, 2026 at 1:11 AM CEST, David Windsor wrote:
>> On Fri, Jul 31, 2026 at 6:23=E2=80=AFPM Paul Moore <[email protected]>=
 wrote:
>>>
>>> On Fri, Jul 31, 2026 at 6:04=E2=80=AFPM Kumar Kartikeya Dwivedi
>>> <[email protected]> wrote:
>>> > On Fri Jul 31, 2026 at 11:49 PM CEST, Paul Moore wrote:
>>> > > On Fri, Jul 31, 2026 at 5:29=E2=80=AFPM Kumar Kartikeya Dwivedi
>>> > > <[email protected]> wrote:
>>> > >> On Fri Jul 31, 2026 at 10:48 PM CEST, Paul Moore wrote:
>>> > >> > On Fri, Jul 31, 2026 at 4:16=E2=80=AFPM Kumar Kartikeya Dwivedi
>>> > >> > <[email protected]> wrote:
>>> > >> >> On Fri Jul 31, 2026 at 10:01 PM CEST, Paul Moore wrote:
>>> > >> >> > On Fri, Jul 31, 2026 at 3:20=E2=80=AFPM Kumar Kartikeya Dwive=
di
>>> > >> >> > <[email protected]> wrote:
>>> > >> >> >> On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote:
>>> > >> >> >> > On Fri, Jul 31, 2026 at 2:50=E2=80=AFPM Kumar Kartikeya Dw=
ivedi
>>> > >> >> >> > <[email protected]> wrote:
>>> > >> >> >> >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote:
>>> > >> >> >> >> > On Fri, Jul 31, 2026 at 2:18=E2=80=AFPM Kumar Kartikeya=
 Dwivedi
>>> > >> >> >> >> > <[email protected]> wrote:
>>> > >> >> >> >> >> On Fri Jul 31, 2026 at 6:59 PM CEST, Paul Moore wrote:
>>> > >> >> >> >> >> > On Fri, Jul 31, 2026 at 12:32=E2=80=AFPM Kumar Karti=
keya Dwivedi
>>> > >> >> >> >> >> > <[email protected]> wrote:
>>> > >> >> >> >> >> >> On Fri Jul 31, 2026 at 6:02 PM CEST, Paul Moore wro=
te:
>>> > >> >> >> >> >> >> > On Fri, Jul 31, 2026 at 11:44=E2=80=AFAM Kumar Ka=
rtikeya Dwivedi
>>> > >> >> >> >> >> >> > <[email protected]> wrote:
>>> > >> >> >> >> >> >> >> On Fri Jul 31, 2026 at 5:30 PM CEST, David Winds=
or wrote:
>>> > >> >> >> >> >> >> >> > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul =
Moore <[email protected]> wrote:
>>>
>>> ...
>>>
>>> > As a consequence, everyone suffers because they first need to satisfy=
 your whims
>>> > on how all code and kfuncs written thus far are wrong, and need to be=
 moved
>>> > around ASAP, including the one being proposed.
>>>
>>> That's not a reasonble or truthful summary of things, I've only
>>> requested that David locate his proposed kfunc in
>>> security/bpf_lsm_kfuncs.c, I never suggested he move any others.
>>>
>>
>> Looking at what's left of the kfunc itself, it's basically nothing.
>> Everything meaningful has been moved into security/ already.
>>
>> Aside from bpf dynptr ops, what's left is:
>>
>> if (!name__str)
>>     return -EINVAL;
>>
>
> You can actually lose this one, the verifier should prevent passing NULL =
for
> name__str. Other functions don't check it either. Feel free to check it, =
or add

.. and I meant, feel free to double check that passing NULL indeed fails ju=
st in
case.

> a negative test in case you're worried about it.
>
>> if (strncmp(name__str, XATTR_BPF_LSM_SUFFIX, sizeof(XATTR_BPF_LSM_SUFFIX=
) - 1))
>>     return -EPERM;
>>
>> if (!xattrs->xattrs)
>>     return -EOPNOTSUPP;
>>
>> ... then a call to security_lsmxattr_add. Why not move this chunk into
>> security_lsmxattr_add, and leave the remaining bits, which are pure
>> bpf, in fs/ for now, and litigate the total placement of all of them
>> once v7 lands?
>>
>
> I wouldn't bother, everything LSM specific is already where it belongs.  =
That
> said, your question is a good demonstration of the absurdity of the ask h=
ere.
>
>>> --
>>> paul-moore.com