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

[Paul Moore]

On Mon, Oct 2, 2023 at 1:06 PM Kees Cook <keescook at chromium.org> wrote:
> 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 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?
>
> 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.)

Tetsuo, just in case there is any doubt in your mind, I agree with
Kees' comments above and I reaffirm my previous statement about LSM ID
guarantees.

As far as I can tell this RFC isn't really about dynamically loadable
LSMs, it's about blocking the LSM syscall work, specifically the LSM
ID tokens.  As I've said many times before, the LSM ID concept is
moving forward and if you can't respect that decision, at least stop
wasting our time.

-- 
paul-moore.com