On Fri, Jan 27, 2023 at 03:16:38PM -0500, Paul Moore wrote: > On Thu, Jan 19, 2023 at 6:10 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > > > > # Background > > > > LSM hooks (callbacks) are currently invoked as indirect function calls. These > > callbacks are registered into a linked list at boot time as the order of the > > LSMs can be configured on the kernel command line with the "lsm=" command line > > parameter. > > Thanks for sending this KP. I had hoped to make a proper pass through > this patchset this week but I ended up getting stuck trying to wrap my > head around some network segmentation offload issues and didn't quite > make it here. Rest assured it is still in my review queue. > > However, I did manage to take a quick look at the patches and one of > the first things that jumped out at me is it *looks* like this > patchset is attempting two things: fix a problem where one LSM could > trample another (especially problematic with the BPF LSM due to its > nature), and reduce the overhead of making LSM calls. I realize that > in this patchset the fix and the optimization are heavily > intermingled, but I wonder what it would take to develop a standalone > fix using the existing indirect call approach? I'm guessing that is > going to potentially be a pretty significant patch, but if we could > add a little standardization to the LSM hooks without adding too much > in the way of code complexity or execution overhead I think that might > be a win independent of any changes to how we call the hooks. > > Of course this could be crazy too, but I'm the guy who has to ask > these questions :) Hm, I am expecting this patch series to _not_ change any semantics of the LSM "stack". I would agree: nothing should change in this series, as it should be strictly a mechanical change from "iterate a list of indirect calls" to "make a series of direct calls". Perhaps I missed a logical change? -- Kees Cook
