On Mon, Jul 20, 2026 at 5:24 PM Kumar Kartikeya Dwivedi <[email protected]> wrote: > On Mon Jul 20, 2026 at 10:15 PM CEST, Paul Moore wrote: > > On Mon, Jul 20, 2026 at 2:27 PM Kumar Kartikeya Dwivedi > > <[email protected]> wrote: > >> On Mon Jul 20, 2026 at 8:12 PM CEST, David Windsor wrote: > >> > On Thu, Jul 16, 2026 at 5:55 PM Paul Moore <[email protected]> wrote: > >> >> > >> >> > >> >> I'm sorry David, now that I'm seeing this function again, especially > >> >> with the LSM specific bits extracted into a LSM function, this > >> >> absolutely > >> >> belongs somewhere under security/. It's only callable from within a > >> >> BPF LSM callback and all it does outside of some BPF pointer boilerplate > >> >> is call right back into a LSM helper function. > >> >> > >> >> If the BPF maintainers aren't willing to accept that, then we will all > >> >> need to find another way. > >> > > >> > Where this code lands doesn't matter to me, so I'll stay out of the > >> > decision of where it lives. > > > > Yes, you're caught up in some territorial wrangling that goes a fair > > bit beyond what you're looking to accomplish. My apologies for my > > half of that, it is an unfortunate part of upstream kernel > > development. > > > >> > If this kfunc goes to security/, would we also want to move eg > >> > bpf_set_dentry_xattr similarly? > >> > > >> > I'll roll v6 of this series meanwhile and we'll see what the BPF > >> > maintainers say. > > > > Thanks. Fortunately, it should be easy enough to move the kfunc > > around, that's likely one of the smaller changes needed in v6. > > > >> I don't think there was any preference expressed from the BPF side. > > > > Look at the second patch in the v4 patchset, you'll see a preference. > > > >> Logically, > >> one cannot be faulted for adding a kfunc to set the xattr for inode in the > >> same > >> file where similar kfuncs to set xattr on other FS objects / entities > >> exist. > > > > First off, I can't say that the existing BPF kfuncs intended for use > > within a BPF LSM program are in a good location. Unlike every other > > LSM which locates its code under security, the BPF LSM devs have > > chosen to locate their associated code all over the place. Some of > > that happened before I was responsible for the LSM framework, and some > > of that which has happened afterwards has likely intentionally avoided > > traditional LSM review. Unfortunately, this has muddied things with > > respect to what is possible generally in BPF versus what is possible > > only when the BPF LSM is enabled; we just recently saw where this was > > arguably the root cause of an exploitable vulnerability. > > > >> The question about bpf_set_dentry_xattr is thus valid. > > > > It's a very valid question. It is my opinion that kfuncs which are > > only intended to be called from within BPF LSMs should be located > > under security/, just like every other LSM. If there is a kfunc that > > is generally useful from other contexts, that is a different story, > > but in the bpf_set_dentry_xattr() case, it is explicitly only useful > > for setting 'security.bpf.*' xattrs. > > I don't think we should do that in v6 though.
Yes, that would be a separate effort and it's one of the reasons I didn't bring it up in my review comments, I was simply responding to those who raised it as a question. -- paul-moore.com
