On 10/1/2023 3:51 AM, Tetsuo Handa wrote: > On 2023/09/25 20:22, KP Singh wrote: >>> 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. >> I think this needs to be discussed if and when we allow LKM based LSMs. > It is *now* (i.e. before your proposal is accepted) that we need to discuss. > >> One needs to know MAX_LSM_COUNT at compile time (not via kernel >> command line), I really suggest you try out your suggestions before >> posting them. I had explained this to you earlier, you still chose to >> ignore and keep suggesting stuff that does not work. > Your proposal needs to know MAX_LSM_COUNT at compile time, that's why > we need to discuss now. > >> We will see when this happens. I don't think it's a difficult problem >> and there are many ways to implement this: >> >> * Add a new slot(s) for modular LSMs (One can add up to N fast modular LSMs) >> * Fallback to a linked list for modular LSMs, that's not a complexity. >> There are serious performance gains and I think it's a fair trade-off. >> This isn't even complex. > That won't help at all. This is exactly the solution I have been contemplating since this discussion began. It will address the bulk of the issue. I'm almost mad/crazy enough to produce the patch to demonstrate it. Almost. There are still a bunch of details (e.g. shared blobs) that it doesn't address. On the other hand, your memory management magic doesn't address those issues either. > You became so blind because what you want to use (i.e. > SELinux and BPF) are already supported by Linux distributors. The reason I'm > insisting on supporting LKM-based LSMs is that Linux distributors cannot afford > supporting minor LSMs. > > Dave Chinner said > > Downstream distros support all sorts of out of tree filesystems loaded > via kernel modules > > at https://lkml.kernel.org/r/ZQo94mCzV7hOrVkh@xxxxxxxxxxxxxxxxxxx , and e.g. > antivirus software vendors use out of tree filesystems loaded via kernel > modules (because neither the upstream kernel community nor the Linux distributors > can afford supporting out of tree filesystems used by antivirus software vendors). > > If Linux distributors decide "we don't allow loading out of tree filesystems > via kernel modules because we can't support", that's the end of the world for > such filesystems. > > What I'm saying is nothing but s/filesystem/LSM/g . > If Linux distributors decide "we don't allow loading out of tree LSMs > via kernel modules because we can't support", that's the end of the world for > LKM-based LSMs. > > The mechanism which makes LKM-based LSMs possible must not be disabled by > the person/organization who builds the vmlinux. > > You might still say that "You can build your vmlinux and distribute it", but > that is also impossible in practice. Some device drivers are meant to be loaded > for Linux distribution's prebuilt kernels. Also, debuginfo package is needed for > analyzing vmcore. Building vmlinux and distributing it is not practical without > becoming a well-known Linux distributors enough to get out-of-tree device drivers > being prebuilt (such as Red Hat). > > Again, you are so blind. > >> Now, this patch and the patch that makes security_hook_heads >> __ro_after_init by removing CONFIG_SECURITY_HOOKS_WRITABLE breaks your >> hack. > Like I demonstrated at https://lkml.kernel.org/r/cc8e16bb-5083-01da-4a77-d251a76dc8ff@xxxxxxxxxxxxxxxxxxx , > removing CONFIG_SECURITY_HOOKS_WRITABLE does not break my hack. >
