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

[Tetsuo Handa]

On 2023/11/02 19:01, KP Singh wrote:
> On Thu, Nov 2, 2023 at 10:42 AM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>>
>> I didn't get your response on https://lkml.kernel.org/r/c588ca5d-c343-4ea2-a1f1-4efe67ebb8e3@I-love.SAKURA.ne.jp .
>>
>> Do you agree that we cannot replace LKM-based LSMs with eBPF-based access control mechanisms,
>> and do you admit that this series makes LKM-based LSMs more difficult to use?
> 
> If you want to do a proper in-tree version of dynamic LSMs. There can
> be an exported symbol that allocates a dynamic slot and registers LSM
> hooks to it. This is very doable, but it's not my use case so, I am
> not going to do it.
> 
> No it does not make LKM based LSMs difficult to use. I am not ready to
> have that debate again.  I suggested multiple extensions in my replies
> which you chose to ignore.

You said

  I think this needs to be discussed if and when we allow LKM based LSMs."

as a response to

  It is Casey's commitment that the LSM infrastructure will not forbid LKM-based LSMs.
  We will start allowing LKM-based LSMs. But it is not clear how we can make it possible to
  allow LKM-based LSMs.

, and you suggested combination of static calls (for built-in LSMs) and
linked list (for LKM-based LSMs).

So, what is your answer to

  Until I hear the real limitations of using BPF, it's a NAK from me.

? Do you agree to allow dynamically appendable LSM modules?