Re: LSM stacking in next for 6.1?

On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp&gt; wrote: > Casey's patchset is trying to provide LSM ID Repository for userspace programs. > But an LSM ID value cannot be assigned to that LSM unless that module is > available in the upstream kernel. This means that, developers are not allowed > to develop a new LSM module even with the intention to become available in the > upstream kernel, for there always is a risk of LSM ID collision which the LSM ID > Repository should have avoided from the beginning. Also, this means that, unlike > PCI devices, users are not allowed to use out-of-tree LSM modules which have to > remain out-of-tree due to proposed-but-not-accepted by the upstream kernel. > This is a serious bug; is LSM a proprietary/closed code where modification is > impossible due to an End-User License Agreement? You are way off in the weeds with false equivalencies. > You have only three choices: > > (1) allow assigning LSM ID integer value to all LSM modules (regardless of > whether that module was merged into upstream kernel) We are not hardware manufacturers. > (2) use module name string value as LSM ID This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution. > (3) dynamically assign LSM ID integer value when an LSM module is registered Again, send a patch. > There never is fourth choice: > > (4) assigning LSM ID integer value to only LSM modules which were merged > into upstream kernel > > The fourth choice is complete lockout of out of tree projects. This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?