On Fri, Jul 21, 2023 at 11:35 AM Paolo Abeni <pabeni@xxxxxxxxxx> 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. > > 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! KP, the BPF LSM maintainer, has posted patches to move the LSM hooks over to static calls, but to the best of my current understanding the patchset intermingles a bug fix with the performance improvements, which I want to avoid. There have been updated patchsets posted, but the original link (below) contains my comments: https://lore.kernel.org/linux-security-module/20230119231033.1307221-1-kpsingh@xxxxxxxxxx/ -- paul-moore.com
