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

[Tetsuo Handa]

On 2023/10/02 0:44, Kees Cook wrote:
> 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.

Excuse me? If the LSM community wants the assignment sequential, the LSM community
cannot admit the LSM value assigned to a not-yet-in-tree LSM.

If "Okay, sounds good." does not imply that the LSM community admits the LSM value
assigned to a not-yet-in-tree LSM, what did "Okay, sounds good." mean?