On Tue, May 5, 2026 at 4:02 AM Paul Moore <[email protected]> wrote: > > On Mon, May 4, 2026 at 7:09 PM Song Liu <[email protected]> wrote: > > On Tue, May 5, 2026 at 12:42 AM Paul Moore <[email protected]> wrote: > > [...] > > > > > Perhaps I'm simply not seeing it, but is there a check to ensure that > > > > > there is only one BPF LSM calling into security_inode_init_security() > > > > > at any given time? With the BPF LSM only reserving a single xattr > > > > > slot, multiple loaded BPF LSM programs providing > > > > > security_inode_init_security() callbacks will be a problem. > > > > > > > > I don't think there is such a check. Also, a single BPF LSM function > > > > may call the kfunc multiple times, which is also problematic. > > > > > > > > I think we will need to make the default bigger, and also introduce > > > > some realloc mechanism for the worst case scenario. This should > > > > work, but the code might be a bit messy. > > > > > > Thanks for the clarification, that is what I was afraid of when > > > looking at the code, but I was hoping I was just missing it. > > > > > > Increasing the default is an option, but I don't think we want to > > > support a dynamic reallocation scheme for the xattr slots, that will > > > likely get extremely messy with synchronization between the LSM > > > framework and BPF LSM hook registrations as well as special code to > > > handle inodes with lifetimes that are disjoint from the BPF LSM > > > programs ... I suppose there may be a way to do it, but it will surely > > > be ugly and come at a cost. > > > > BPF trampoline already handles all the synchronizations, such as > > add hook, remove hook, etc. properly. So this is not that hard. > > How do you plan to handle the issue of disjoint lifetimes? > > > All we really need is to allocate a new array, copy pointers, and free > > the old array. And we only really need this in the worst case > > scenarios. > > Oh, is that all? :D > > Keep in mind that the code must also handle arbitrary ordering of > LSMs; in other words, you must handle a BPF LSM that isn't at the end > of the LSM order. While a BPF LSM at the end of the LSM list is the > most common, and recommended ordering for the vast majority of users, > we've been working to make the ordering as generalized as possible.
All the BPF LSM hooks are called together, so it should be fine. Maybe I missed some corner cases. Either way, I agree with David that we don't need too many xattrs. Since BPF LSM is reserved to the privileged users only, it is safe to put a reasonable limit, say 4 or 8, and do not handle the realloc. If the admin would like to brick a system with BPF LSM, there are many other ways to do it. Thanks, Song
