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. 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. Thanks, Song
