On Mon, Sep 18, 2023 at 11:24:59PM +0200, KP Singh wrote: > This config influences the nature of the static key that guards the > static call for LSM hooks. > > When enabled, it indicates that an LSM static call slot is more likely > to be initialized. When disabled, it optimizes for the case when static > call slot is more likely to be not initialized. > > When a major LSM like (SELinux, AppArmor, Smack etc) is active on a > system the system would benefit from enabling the config. However there > are other cases which would benefit from the config being disabled > (e.g. a system with a BPF LSM with no hooks enabled by default, or an > LSM like loadpin / yama). Ultimately, there is no one-size fits all > solution. > > with CONFIG_SECURITY_HOOK_LIKELY enabled, the inactive / > uninitialized case is penalized with a direct jmp (still better than > an indirect jmp): > [...] > index 52c9af08ad35..bd2a0dff991a 100644 > --- a/security/Kconfig > +++ b/security/Kconfig > @@ -32,6 +32,17 @@ config SECURITY > > If you are unsure how to answer this question, answer N. > > +config SECURITY_HOOK_LIKELY > + bool "LSM hooks are likely to be initialized" > + depends on SECURITY > + default y > + help > + This controls the behaviour of the static keys that guard LSM hooks. > + If LSM hooks are likely to be initialized by LSMs, then one gets > + better performance by enabling this option. However, if the system is > + using an LSM where hooks are much likely to be disabled, one gets > + better performance by disabling this config. Since you described the situations where it's a net benefit, this could be captured in the Kconfig too. How about this, which tracks the "major" LSMs as in the DEFAULT_SECURITY choice: depends on SECURITY && EXPERT default BPF_LSM || SECURITY_SELINUX || SECURITY_SMACK || SECURITY_TOMOYO || SECURITY_APPARMOR -- Kees Cook
