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. 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.
