On 2024/09/06 23:24, Paul Moore wrote: > On Fri, Sep 6, 2024 at 3:43 AM Tetsuo Handa > <pengu****@i-lov*****> wrote: >> If you ignore my concern, I have to NACK the static call changes you are >> going to send in the upcoming merge window. > > I'm not ignoring your concern, I've responded to your emails and > patches on the topic over, and over, and over, and over again by > trying to explain to you that your goal of supporting out-of-tree LSMs > regardless of the impact to the upstream LSM effort is not something > that is acceptable to the upstream LSM effort, or the Linux kernel in > general. I want LKM-based LSM support in order to allow one of in-tree LSMs (namely TOMOYO) to be delivered to my intended users, for nobody can solve the realities that commit 20510f2f4e2d ("security: Convert LSM into a static interface") missed: how difficult/unrealistic for Linux users who are using prebuilt kernel packages provided by Linux distributors to replace their kernels how difficult for Linux distributors to allow their users to use in-tree LSM modules which that distributor is not familiar with [1] because Linux distributors are supposed to support kernel packages they built and shipped Linux distributors do not want to enable out-of-tree code due to upstream first policy, while Linux kernel development community can not afford accepting whatever proposed code due to limited resources One of LSM developers commented me ( Mon, 22 Jul 2024 17:12:05 +0200 in off-list discusstion) about AKARI Ofcourse you found a way to hack it. You want me to curl bash pipe your kernel module code that disables certain protections and runs arbitrary hacks on my machine? No thank you! Ofcourse you change the memory mapping of data. You are misleading your users into trusting you and instead of contributing code and working with distros for your use case, you are shipping hacks and making noise without any constructive code contribution or alignment with distros for your use-case (below RHEL won't eneable it even if we had a proper API). and this patch is for following that comment. All concerns about updating __ro_after_init data is gone if we move to a dual static call and linked list based approach. I'm very very very sad that you did not respond to 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. in [2], and started saying "No" to this approach after you accepted the static call changes. You are ignoring my concern! Link: https://bugzilla.redhat.com/show_bug.cgi?id=542986 [1] Link: https://lkml.kernel.org/r/CACYk****@mail***** [2]
TOMOYO
Fork