On Mon, Feb 06, 2023 at 07:41:04PM +0100, KP Singh wrote:

On Mon, Feb 6, 2023 at 7:29 PM Casey Schaufler [off-list ref] wrote:

quoted

On 2/6/2023 9:48 AM, Song Liu wrote:

quoted

On Mon, Feb 6, 2023 at 8:29 AM Casey Schaufler [off-list ref] wrote:

quoted

On 2/6/2023 5:04 AM, KP Singh wrote:

quoted

On Fri, Jan 20, 2023 at 5:36 AM Kees Cook [off-list ref] wrote:

quoted

On Fri, Jan 20, 2023 at 01:08:17AM +0100, KP Singh wrote:

quoted

The indirect calls are not really needed as one knows the addresses of

[...]

quoted

quoted

+/*
+ * Define static calls and static keys for each LSM hook.
+ */
+
+#define DEFINE_LSM_STATIC_CALL(NUM, NAME, RET, ...)                  \
+     DEFINE_STATIC_CALL_NULL(LSM_STATIC_CALL(NAME, NUM),             \
+                             *((RET(*)(__VA_ARGS__))NULL));          \
+     DEFINE_STATIC_KEY_FALSE(SECURITY_HOOK_ENABLED_KEY(NAME, NUM));

Hm, another place where we would benefit from having separated logic for
"is it built?" and "is it enabled by default?" and we could use
DEFINE_STATIC_KEY_MAYBE(). But, since we don't, I think we need to use
DEFINE_STATIC_KEY_TRUE() here or else won't all the calls be
out-of-line? (i.e. the default compiled state will be NOPs?) If we're
trying to optimize for having LSMs, I think we should default to inline
calls. (The machine code in the commit log seems to indicate that they
are out of line -- it uses jumps.)

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.

It's a trade off that will work differently for different LSMs and
distros (based on the LSM they chose) and this the config option. I
even suggested this be behind CONFIG_EXPERT (which is basically says
this:

 "This option allows certain base kernel options and settings
 to be disabled or tweaked. This is for specialized
 environments which can tolerate a "non-standard" kernel.
 Only use this if you really know what you are doing."

Using the DEFINE_STATIC_KEY_MAYBE() and static_branch_maybe() macros
tied to a new CONFIG seems like it can give us a reasonable knob for
in-line vs out-of-line calls.

quoted

quoted

quoted

quoted

 But I do see that there are LSMs that have these
enabled. Maybe we can put this behind a config option, possibly
depending on CONFIG_EXPERT?

Help me, as the maintainer of one of those LSMs, understand why that would
be a good idea.

IIUC, this is also from performance concerns. We would like to manage
the complexity at compile time for performance benefits.

What complexity? What config option? I know that I'm slow, but it looks
as if you're suggesting making the LSM infrastructure incredibly fragile
and difficult to understand.

I am sorry but the LSM is a core piece of the kernel that currently
has significant unnecessary overheads (look at the numbers that I
posted) and this not making it fragile, it's making it performant,
such optimisations are everywhere in the kernel and the LSM
infrastructure has somehow been neglected and is just catching up.
These are resources being wasted which could be saved.

Let's just move forward to v2, which I think will look much cleaner. I
think we can get to both maintainable code and run-time performance with
this series.

-- 
Kees Cook