ANN: new LSM guidelines

[Paul Moore]

On Tue, Sep 12, 2023 at 2:40 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 9/12/2023 11:08 AM, Paul Moore wrote:
> >
> > Once again, we've already discussed this many, many times: out-of-tree
> > LSMs are not the priority and that is not going to change.  One
> > corollary of this is that we are not going to assign LSM IDs to LSMs
> > that remain out-of-tree as this would negatively impact the LSM layer
> > by cluttering/depleting the LSM ID space.  LSMs that are working
> > towards integration with the upstream Linux kernel can self-assign a
> > temporary LSM ID which will be finalized upon merging in the LSM tree.
> > Based on all of the arguments you have already submitted - and let us
> > be very clear: you are the only one speaking out against this - I see
> > no reason to change this policy.
>
> I won't say this is a great idea, or that I endorse it, but we could
> allocate a range of LSM ID values ( 10000 - 10999 ? ) that we promise
> will never be given to an upstream LSM. We wouldn't make any guarantees
> about conflicts otherwise. These could be used by LSMs before they are
> accepted upstream or by LSMs that don't have upstream aspirations. I
> seriously doubt that anyone using such an LSM is going to be mixing
> multiple such LSMs without being capable of managing ID conflicts.

Not a crazy idea.  I had debated something similar, a reserved
"private use" or "experimentation" range; there is definitely
precedence for that in other areas, e.g. network protocols.  What held
me back is that invariably folks will want to create long-term
persistent registrations against this space for their out-of-tree LSMs
which would require some sort of unofficial, adhoc registration
authority which starts to get a bit silly in my opinion (the
registration authority for the Linux kernel API is the upstream Linux
kernel community).

Temporary assignments while a LSM is undergoing the review-revision
cycle on its way to being merged is something different and if we need
a couple of reserved numbers for that (one or two MAX) we can consider
that, but I don't expect this to be a major problem in practice.  LSMs
that are in this transient pre-merge state shouldn't be used for
production purposes and thus a LSM ID change on merging shouldn't be a
problem.

-- 
paul-moore.com