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. -- paul-moore.com
