On Tue, May 5, 2026 at 5:00 AM Song Liu <[email protected]> wrote: > 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.
I was thinking about the LSM framework as a whole, not just the potential for multiple BPF programs attached to the BPF LSM. > 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. That is definitely the easier route. However, please add code to ensure the number of attached BPF programs is limited to the number of requested slots. -- paul-moore.com
