[PATCH 04/10] CaitSith: Add header file.

[Paul Moore]

On Wed, Nov 9, 2022 at 11:12 PM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2022/11/10 11:22, Kees Cook wrote:
> > On November 9, 2022 3:57:06 PM PST, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
> >> On 2022/11/09 23:48, Paul Moore wrote:
> >>>                                             If there is a significant
> >>> change, e.g. the overall kernel policy towards out-of-tree code, we
> >>> can reconsider this policy but as of right now only upstream LSMs will
> >>> have LSM ID tokens assigned to them; in-development LSMs are free to
> >>> temporarily assign themselves an ID token (which may change when the
> >>> LSM is merged upstream), and out-of-tree LSMs are free to do whatever
> >>> they like with respect to their code, just as they do now.
> >>
> >> If in-development LSMs and out-of-tree LSMs cannot get a stable ID token,
> >> developers cannot write and publish userspace tools which make use of ID
> >> token. If ID collision happens by use of temporarily ID token, this token
> >> is no longer an identifier. That is a pointless and needless constraint
> >> for getting LSM modules created / tested / used.
> >
> > You have to let this go. You aren't hearing us: this ID reservation process
> > is not a problem for anyone but you. It is the same for all the syscalls
> > that get added, and all the prctls, etc etc. This isn't a problem for userspace
> > tools using those, and there won't be a problem here either.
> >
> > We will not support out of tree code, so needing ID stability for out-of-tree
> > LSMs isn't a valid argument.
> >
>
> This ID reservation process is very much a problem for you all.
>
> In https://lkml.kernel.org/r/CAHC9VhQGnEcoYeGpwbbXbMrG1dOvJ=2ohd4zPYoqBJK9p1mSjQ@mail.gmail.com ,
> Paul said that it is becoming increasingly difficult for people to find time to
> review potential new LSMs.

It is important that you understand that difficult does not mean
impossible.  As Kees pointed out the rate of LSM acceptance is roughly
at the same level as the rest of the kernel.  The rate of upstream LSM
review also has very little, if anything, to do with the LSM ID
token/string argument.

Beyond that, I'm trying to be polite, but I completely agree with
Kees' statement that you need to let this go.  We are going to be
moving forward with the LSM ID token over the string values.  I'm
sorry we couldn't come to an agreement that satisfies you, but I'm
done discussing this at this point in time.  We can revisit this
decision if something changes, but in the meantime please let this go;
a decision has been made and I'm no longer considering arguments on
this topic.

-- 
paul-moore.com