On 2/6/2023 11:05 AM, Song Liu wrote: > On Mon, Feb 6, 2023 at 10:29 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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
