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

[Casey Schaufler]

On 2/6/2023 11:05 AM, Song Liu wrote:
> 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?

Yes. Alas, for some security schemes it isn't possible to avoid checks in
hot paths. The assumption that "hot paths are less likely to have LSM hooks
enabled" is not generally valid. The statement is question seems to imply
that it's OK to not optimize hot paths. Maybe I read it wrong. I will hold
off further comment until we see the next version.

>
> Thanks,
> Song