On 2023/11/22 13:41, Paul Moore wrote: > both of these use cases can be solved today by compiling your own kernel. No. Compiling kernels is not a viable option for regular developers/users. We (who are kernel developers) tend to think that compiling/replacing a kernel as a trivial thing. But majority of Linux users do not think so. The kernel is one of most puzzling programs for Linux users, and most of Linux users afraid compiling/replacing kernels. Red Hat's support said that Red Hat does not support a rebuilt RHEL kernel even if that kernel is rebuilt using the same kernel source and the same kernel config shipped by Red Hat. Let alone kernels which are rebuilt with the modified kernel config. Your "compiling your own kernel" answer is asking me to become a Linux distributor and to support the whole rebuilt kernels. That will include management of kernel-debuginfo packages needed for analyzing vmcore, and also management of userspace packages which depend on the kernel package. What do you think if you are obligated to support whatever problems just because you want to allow users to use your code? I'm sure that you will say "I can't". Your answer cannot be satisfied by a kernel developer who can develop/support an LSM module but cannot afford supporting problems that are irrelevant to that LSM module. Being able to use whatever functionality (not only LSM modules but also device drivers and filesystem drivers) using pre-built distribution kernels and pre-built kernel-debuginfo packages is the mandatory baseline. Of course, the best solution is that whatever LSM modules are built into distributor's kernels. But since such solution is impossible ( https://bugzilla.redhat.com/show_bug.cgi?id=542986 ), the second best solution will be that distributor's kernels support only ability to load LSM modules which that distributor's kernels cannot afford supporting as loadable kernel modules, and somebody else other than distributor provides support for LSM modules which that distributor's kernels cannot afford supporting.
