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 PM Paul Moore <[email protected]> wrote: >>> >>> On Fri, Jul 31, 2026 at 6:04 PM 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 PM 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 PM 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 PM Kumar Kartikeya Dwivedi >>> > >> >> > <[email protected]> wrote: >>> > >> >> >> On Fri Jul 31, 2026 at 9:05 PM CEST, Paul Moore wrote: >>> > >> >> >> > On Fri, Jul 31, 2026 at 2:50 PM Kumar Kartikeya Dwivedi >>> > >> >> >> > <[email protected]> wrote: >>> > >> >> >> >> On Fri Jul 31, 2026 at 8:42 PM CEST, Paul Moore wrote: >>> > >> >> >> >> > On Fri, Jul 31, 2026 at 2:18 PM 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 PM 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 AM 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 AM 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 just 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 here. > >>> -- >>> paul-moore.com
