On Thu, Nov 2, 2023 at 11:30 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > 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). Tetsuo, this is exactly a technical solution and it works, a very easy API can be made to enable the LKM based use-case (if the maintainers agree that they want to enable LKM based LSMs) 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. > > So, what is your answer to > > Until I hear the real limitations of using BPF, it's a NAK from me. The burden of proof is on you. All I can say is that if you wanted to implement the policy logic you want, you could. If you cannot, please share specifics and the BPF / LSM community will help. > > ? Do you agree to allow dynamically appendable LSM modules? Nice try, I am for dynamically loadable hook logic, that's why I implemented the BPF LSM. What you want to ask me is am I for LKM LSMs. Regarding the LKM based LSMs, it's my opinion that it should be done with BPF LSM because it's actually safer and does not have the maintenance overhead that a kernel module has. My 0.02c, please share code, specifics and if you like your use case, get it merged with a patch series. From here onwards, I won't be responding to hypotheticals. >
