Re: [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
Paul Moore <[email protected]> Fri, 31 Jul 2026 11:33:09 -0400
| Newsgroups | org.kernel.vger.linux-integrity,org.kernel.vger.bpf,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-security-module,org.kernel.vger.selinux |
|---|---|
| Message-ID | <CAHC9VhQXtV_dGt_b5oD_LFNOygfx=37u6P_S32xo3A5aHvnj-g@mail.gmail.com> |
On Fri, Jul 31, 2026 at 11:30=E2=80=AFAM David Windsor <[email protected]>= wrote: > On Fri, Jul 31, 2026 at 11:17=E2=80=AFAM Paul Moore <[email protected]>= wrote: > > > > > > Okay, it looks like there was some confusion/misunderstanding. > > > > My understanding of Kumar's comments was that he was referring to the > > 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 that > > 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. > > > However, regardless of Kumar's intent, speaking as the LSM maintainer, > > my stance on this is that the kfunc you are proposing must live in > > security/bpf_lsm_kfuncs.c to be acceptable. > > > > Ack, will do this in v7. > > The Landlock series currently up for discussion [1] is proposing > placing its kfuncs in a new kernel/bpf/bpf_lsm.c. Should these maybe > go there? Nope. That patchset has its own issues, one of which is the location of the kfuncs outside of security/; I simply haven't had the time to review that in full and reply. --=20 paul-moore.com