On 7/21/2023 8:34 AM, Paolo Abeni wrote: > Hi all, > > On Mon, 2023-07-17 at 16:27 +0200, Paolo Abeni wrote: >> The only >> remaining perf-related pain-point I see is the indirect call at the >> security_ level, and tackling it looks much more difficult... :( > I spent a little more time on this latest topic. AFAICS recently such > overhead has increased due to the bpf lsm introduction. My > understanding is that a major LSM and BPF LSM simultaneously enabled is > a common usage scenario. That means 2 indirect calls + 2 untrain trails > and 3 additional cache-lines used per hook. > > Under the assumption than having multiple major lsms enabled > concurrently is less common, I hacked some (not exactly spectacularly > beautiful) code to avoid the above. Basically, after initialization, > for a limited number of hooks, it checks if only the default major lsm > and eventually the bpf lsm are registered and if so, converts such > hooks to static call[s], using static branches. K.P. Singh proposed similar changes recently, and Brendan Jackman had something in 2020. The performance benefit demonstrated has been encouraging. The approach has two serious problems. It doesn't lend itself very well to special cases, and the code is incredibly ugly. > > The idea would be to keep the above infra usage restricted to the most > performance-relevant hooks (e.g. one-off initialization or > configuration are not relevant from that perspective). For obvious > reasons I started from a few of network related hooks ;) > > As said the code could be more nice: there is some quite heavy macro > usage and some duplication I was not able to avoid). On the flip side > it shows quite measurable benefit when enabled, 0 impact when disabled, > and it's available to all major LSM, except tomoyo (but even the latter > could be accommodated with some effort). > > If there is some shared interest for the above I can share the current > status and try to cleanup the code. > > Any feedback more then appreciated! > > Cheers, > > Paolo >
