On Fri, Sep 22, 2023 at 4:57 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > 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 :) Thank you for the context Paul, this explains a lot! > > -- > paul-moore.com
