PoC faster LSMs with static calls/keys: ask for feedbacks

[PaulRenauld]

This patch is to ask for comments and suggestions.

This uses static keys and static calls to get rid of the indirect calls for the LSMs.
For each LSM hook, there are 3 "slots" (the number can be changed). A slot corresponds to a static key, which indicates if this slot is used or not, and a static call, which would contain the function to call if the slot is used.
For example, for the hook file_permission, we will define:

DEFINE_STATIC_CALL(static_call_file_permission_1, LSM_FUNC_DEFAULT(file_permission));
DEFINE_STATIC_KEY_FALSE(static_check_file_permission_1);
DEFINE_STATIC_CALL(static_call_file_permission_2, LSM_FUNC_DEFAULT(file_permission));
DEFINE_STATIC_KEY_FALSE(static_check_file_permission_2);
DEFINE_STATIC_CALL(static_call_file_permission_3, LSM_FUNC_DEFAULT(file_permission));
DEFINE_STATIC_KEY_FALSE(static_check_file_permission_3);

Although the static key API provides an array definition, it is not the case for static calls, and it would be non-trivial to add it (code here). It makes it hard to provide a cleaner structure and we cannot use a for-loop to access the slots. Instead, we use a macro FOR_EACH_HOOK_SLOT(M, ...) which will expand.

We also need to keep in mind that not all functions use call_int_hook/call_void_hook. Some access the list directly. Therefore we still need to add the hooks to the linked list. Right now, we cannot have more LSMs on a specific hook than 3. If we want to remove the limit, we could add all the LSM to the hook list, but keep a pointer to the 3rd element. Then, in call_int_hook/call_void_hook, keep the iteration on the list, but start at index 3. This way, the first three LSMs are optimized, and the other have the same cost than before.

[PaulRenauld]

This is probably the ugliest part of this patch (and that's saying something).
Effctively, we will have ~200 ifs in the expanded code, and only one will be used. The difficulty here is that we need a generic solution, but the static calls/keys need to be referenced by their full name at compile time.
One possible solution would be to generate a function add_static_hook_##NAME(...) for each hook, and then modify security_hook_list and its creating macro LSM_HOOK_INIT to include a reference to the function. This would slow down slightly the initialization, and introduce ~200 new functions.

[bjackman]

I think another way to do this is to store the info needed for the static_call_update in the security_hook_list structure.

[PaulRenauld]

This function is defined but never used except for getting its type. We might be able to get rid of them by modifying the static calls.

[bjackman]

Hmm yeah that's a tricky one. This also might present an intermediate solution: we only need one of these default functions for each possible value of (RET, DEFAULT), perhaps we can write some (potentially extremely galaxy-brain) macro hackery to avoid defining a different one for each hook.

[bjackman]

This is dope! I've added some comments which may be too terse, if they don't 'make much sense don't worry as we'll need to discuss this f2f in detail anyawy.

[bjackman]

If we were willing to get deep into the static_call implementation, I think it might be possible to avoid the static key. Let's discuss f2f.

[bjackman]

It's gonna be quite fiddly, but I think instead of having a globally fixed number of slots, and trying to put each hook into a slot one by one, we should try to:

• determine the number of LSMs that exist at compile time, and set the number of slots to that-
• at boot time, fix the mapping from LSMs to slot numbers.

[bjackman]

I think another way to do this is to store the info needed for the static_call_update in the security_hook_list structure.

[bjackman]

Hmm yeah that's a tricky one. This also might present an intermediate solution: we only need one of these default functions for each possible value of (RET, DEFAULT), perhaps we can write some (potentially extremely galaxy-brain) macro hackery to avoid defining a different one for each hook.

[PaulRenauld]

As the original branch on the queue was updated, all these commits were rebased on another branch. See #3 for the updates.