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. 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
