On 2023/11/02 19:01, KP Singh wrote: > On Thu, Nov 2, 2023 at 10:42 AM Tetsuo Handa > <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: >> >> I didn't get your response on https://lkml.kernel.org/r/c588ca5d-c343-4ea2-a1f1-4efe67ebb8e3@xxxxxxxxxxxxxxxxxxx . >> >> 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?
