This functionality will be used by TOMOYO security module. In order to officially use an LSM module, that LSM module has to be built into vmlinux. This limitation has been a big barrier for allowing distribution kernel users to use LSM modules which the organization who builds that distribution kernel cannot afford supporting [1]. Therefore, I've been asking for ability to append LSM hooks from LKM-based LSMs so that distribution kernel users can use LSMs which the organization who builds that distribution kernel cannot afford supporting. In order to unofficially use LSMs which are not built into vmlinux, I've been maintaining AKARI as an LKM-based LSM which can run on kernels between 2.6.0 and 6.6. But KP Singh's "Reduce overhead of LSMs with static calls" proposal will make AKARI more difficult to run because it removes the linked list. Therefore, reviving ability to officially append LSM hooks from LKM-based LSMs became an urgent matter. KP Singh suggested me to implement such LSMs as eBPF programs. But the result is that eBPF is too restricted to emulate such LSMs [2]. Therefore, I still need ability to append LSM hooks from LKM-based LSMs. KP Singh commented I think what you can do is send patches for an API for LKM based LSMs and have it merged before my series, I will work with the code I have and make LKM based LSMs work. If this work gets merged, and your use-case is accepted (I think I can speak for at least Kees [if not others] too here) we will help you if you get stuck with MAX_LSM_COUNT or a dual static call and linked list based approach. at [3] but I made this series on top of "[PATCH v7 0/5] Reduce overhead of LSMs with static calls", for I wanted to know how to use static_calls() and how does appending LSM hooks after boot will look like, with a hope that LSM hooks that are appended after boot can also use static calls so that the same structures/macros can be used for both built-in and loadable LSM modules. The result seems to be that linked list and static_call() are not compatible, for a unique symbol name has to be assigned to each static call. But I felt that we could avoid loop unrolling if we change the direction from "call all individual callbacks from security/security.c" to "call next callback at end of current callback if current callback succeeded and next callback is defined, and security/security.c calls only the first callback". Link: https://lkml.kernel.org/r/9b006dfe-450e-4d73-8117-9625d2586dad@xxxxxxxxxxxxxxxxxxx [1] Link: https://lkml.kernel.org/r/c588ca5d-c343-4ea2-a1f1-4efe67ebb8e3@xxxxxxxxxxxxxxxxxxx [2] Link: https://lkml.kernel.org/r/CACYkzJ7ght66802wQFKzokfJKMKDOobYgeaCpu5Gx=iX0EuJVg@xxxxxxxxxxxxxx [3]
