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

[Kees Cook <keescook@chromium.org>]

On Mon, Oct 02, 2023 at 07:04:27PM +0900, Tetsuo Handa wrote:
> On 2023/10/02 0:44, Kees Cook wrote:
> > On October 1, 2023 4:31:05 AM PDT, Tetsuo Handa <penguin-kernel@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?

I'm saying that if someone participates with upstream correctly, they'll
get a sequential ID since that is the expected process.

And if an LSM is out of tree for years and years in some large ecosystem
that has deeply hard-coded the LSM ID but now wants the LSM to land
upstream, then it's likely that an out-of-sequence ID would be accepted.

My point is that there is nothing technical stopping an out-of-tree LSM
from existing, and that the political issues for bringing a large
out-of-tree LSM upstream are going to have plenty of other negotiations
around maintaining operational behavior, of which and LSM ID is unlikely
to be a sticking point. Every release that some code (LSM or not) is out
of tree makes it that much harder to land upstream. (In other words, the
challenges to upstreaming a long-time-out-of-tree codebase are much
larger than dealing with an out-of-sequence LSM ID.)

-Kees

-- 
Kees Cook