[PATCH RESEND bpf-next 3/4] security: Replace indirect LSM hook calls with static calls

[Song Liu]

On Mon, Feb 6, 2023 at 10:29 AM Casey Schaufler <casey at schaufler-ca.com> wrote:
>
[...]
> >>> I should have added it in the commit description, actually we are
> >>> optimizing for "hot paths are less likely to have LSM hooks enabled"
> >>> (eg. socket_sendmsg).
> >> How did you come to that conclusion? Where is there a correlation between
> >> "hot path" and "less likely to be enabled"?
> > I could echo KP's reasoning here. AFAICT, the correlation is that LSMs on
> > hot path will give more performance overhead. In our use cases (Meta),
> > we are very careful with "small" performance hits. 0.25% is significant
> > overhead; 1% overhead will not fly without very good reasons (Do we
> > have to do this? Are there any other alternatives?). If it is possible to
> > achieve similar security on a different hook, we will not enable the hook on
> > the hot path. For example, we may not enable socket_sendmsg, but try
> > to disallow opening such sockets instead.
>
> I'm not asking about BPF. I'm asking about the impact on other LSMs.
> If you're talking strictly about BPF you need to say that. I'm all for
> performance improvement. But as I've said before, it should be for all
> the security modules, not just BPF.

I don't think anything here is BPF specific. Performance-security tradeoff
should be the same for all LSMs. A hook on the hot path is more expensive
than a hook on a cooler path. This is the same for all LSMs, no?

Thanks,
Song