[PATCH v4 0/5] Reduce overhead of LSMs with static calls

[Mateusz Guzik]

On 9/23/23, Mateusz Guzik <mjguzik at gmail.com> wrote:
> On 9/23/23, KP Singh <kpsingh at kernel.org> wrote:
>> On Fri, Sep 22, 2023 at 8:42 PM Mateusz Guzik <mjguzik at gmail.com> wrote:
>>>
>>> On Fri, Sep 22, 2023 at 04:55:00PM +0200, KP Singh wrote:
>>> > Since we know the address of the enabled LSM callbacks at compile time
>>> > and only
>>> > the order is determined at boot time, the LSM framework can allocate
>>> > static
>>> > calls for each of the possible LSM callbacks and these calls can be
>>> > updated once
>>> > the order is determined at boot.
>>> >
>>>
>>> Any plans to further depessimize the state by not calling into these
>>> modules if not configured?
>>>
>>> For example Debian has a milipede:
>>> CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf"
>>>
>>> Everything is enabled (but not configured).
>>
>> If it's not configured, we won't generate static call slots and even
>> if they are in the CONFIG_LSM (or lsm=) they are simply ignored.
>>
>
> Maybe there is a terminology mismatch here, so let me be more specific
> with tomoyo as an example.
>
> In debian you have:
> CONFIG_SECURITY_TOMOYO=y
>
> CONFIG_LSM, as per above, includes it on the list.
>
> At the same time debian does not ship any tooling to configure tomoyo
> -- it is compiled into the kernel but not configured to enforce
> anything.
>
> On stock kernel this results in tons of calls to
> tomoyo_init_request_info, which are quite expensive due to an
> avoidable memset thrown in, and which always return
> tomoyo_init_request_info.
>

Erm, which always return TOMOYO_CONFIG_DISABLED.

> Does not look like your patch whacks this problem.
>

So I am asking if there are plans to make these modules get out of the
way if they have nothing to do, like tomoyo in the example above.

Of course preferably distros would not make these weird configs, but I
suspect this ship has sailed.

-- 
Mateusz Guzik <mjguzik gmail.com>