[RFC PATCH 1/2] LSM: Allow dynamically appendable LSM modules.

[Kees Cook]

On October 1, 2023 4:31:05 AM PDT, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
>Kees Cook said there is no problem if the policy of assigning LSM ID value were
>
>  1) author: "Hello, here is a new LSM I'd like to upstream, here it is. I assigned
>              it the next LSM ID."
>     maintainer(s): "Okay, sounds good. *review*"
>
>  2) author: "Hello, here is an LSM that has been in active use at $Place,
>              and we have $Xxx many userspace applications that we cannot easily
>              rebuild. We used LSM ID $Value that is far away from the sequential
>              list of LSM IDs, and we'd really prefer to keep that assignment."
>    maintainer(s): "Okay, sounds good. *review*"
>
>and I agreed at https://lkml.kernel.org/r/6e1c25f5-b78c-8b4e-ddc3-484129c4c0ec@I-love.SAKURA.ne.jp .
>
>But Paul Moore's response was
>
>  No LSM ID value is guaranteed until it is present in a tagged release
>  from Linus' tree, and once a LSM ID is present in a tagged release
>  from Linus' tree it should not change.  That's *the* policy.
>
>which means that the policy is not what Kees Cook has said.

These don't conflict at all! Paul is saying an ID isn't guaranteed in upstream until it's in upstream. I'm saying the id space is large enough that you could make a new out of tree LSM every second for the next billion years. The upstream assignment process is likely sequential, but that out of sequence LSMs that show a need to be upstream could make a case for their existing value.

But again, I've already demonstrated how there is nothing technical blocking out of tree LSMs. If you want a declarative statement that some theoretical code will land upstream, you will not get it. And that's just normal FLOSS development: any number of technical, social, or political things may cause code to go unaccepted.

-Kees


-- 
Kees Cook