On Fri, Sep 22, 2023 at 7:25 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > On 2023/09/21 22:58, KP Singh wrote: > > Yeah, LSMs are not meant to be used from a kernel module. The data > > structure is actually __ro_after_init. So, I am not even sure how you > > are using it in kernel modules (unless you are patching this out). > > And, if you are really patching stuff to get your out of tree LSMs to > > work, then you might as well add your "custom" LSM config here or just > > override this count. > > I'm using LKM-based LSM with any version between 2.6.0 and 6.6-rc2, without patching > __ro_after_init out. We can load LKM-based LSMs, without patching the original kernel. > And it seems to me that several proprietary security products for Linux are using > this trick, for LSMs for such products cannot be built into distributor's kernels... ... > > The performance benefits here outweigh the need for a completely > > unsupported use case. > > LKM-based LSMs are not officially supported since 2.6.24. But people need LKM-based LSMs. > It is very sad that the LSM community is trying to lock out out of tree LSMs > ( https://lkml.kernel.org/r/ec37cd2f-24ee-3273-c253-58d480569117@xxxxxxxxxxxxxxxxxxx ). > The LSM interface is a common property for *all* Linux users. > > I'm not objecting the performance benefits by replacing with static calls. > I'm not happy that the LSM community ignores the Torvald's comment at https://lkml.org/lkml/2007/10/1/192 > and does not listen to minority's voices. Despite a previous comment that I was done engaging with Tetsuo on this topic, I feel it is worth commenting here as there are a number of people on the To/CC line that have likely not been following the related discussion threads on the LSM list. First and foremost I want to reiterate that the LSM community's first priority are those LSMs which have been accepted and merged into the upstream Linux kernel. While I have no intention, or desire, to harm out-of-tree LSMs, I stand firm that we should not compromise designs for in-tree LSMs/functionality solely to benefit out-of-tree LSMs. I believe this is consistent, or at least compatible, with the general Linux kernel community's stance on in-tree vs out-of-tree code. The (relatively) newly proposed LSM syscalls have proven to be a contentious topic between Tetsuo and the LSM community as a whole; I won't rehash the arguments here, as they are all available on lore.kernel.org (simply look for any threads that Tetsuo has been involved in over the past several months) but we have discussed this issue at great length and Tetsuo remains the only opposing opinion. It was my hope that Tetsuo would respect the opinion of the upstream LSM community, even if he didn't agree with the details. After all, this is how we move forward in cases where differing opinions cannot all be accommodated in the code. Unfortunately Tetsuo's continued and stubborn refusal to accept the majority opinion has started to spill into other discussion threads, disrupting the discussion there and twisting some of the core issues to better fit his arguments. Not only is this frustrating, it is becoming rather disruptive. My suggestion is to simply follow some classic Internet advice and "don't feed the trolls". As we discussed off-list (and in-person!) this week, I am generally supportive of work that improves performance, but correctness will always be my priority with maintainability a close second. We have a few more pressing issues at the LSM layer which are demanding my time at the moment, but I do promise to come back to this issue/patchset as these other high priority issues are resolved. Thanks for your patience and understanding KP :) -- paul-moore.com
