linux-kernel - Re: [GIT PULL] tomoyo update for v6.12

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241011170617.GA5139@wind.enjellic.com>
Date: Fri, 11 Oct 2024 12:06:18 -0500
From: "Dr. Greg" <greg@...ellic.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: Paul Moore <paul@...l-moore.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org
Subject: Re: [GIT PULL] tomoyo update for v6.12

On Tue, Oct 08, 2024 at 11:25:16AM -0700, Casey Schaufler wrote:

Good morning, I hope the week has gone well for everyone.

> On 10/8/2024 4:14 AM, Dr. Greg wrote:
> > ...
> >
> > Which we also believe justifies more attention than what it has been
> > able to receive in 20 months.
> 
> You're right. You're also not alone. There are things that you can do
> that will help get the review you're looking for. Developers who attend
> to the needs and preferences of reviewers get a whole lot more attention
> than those who fuss and fume about not getting what they "deserve". My
> hopefully constructive recommendations are:

We put a significant body of code and engineering time on the table to
try and improve the Linux security ecosystem.  We did this because in
certain circles the value of our approach is understood and there was
a desire to have it more generally available.

We don't believe we 'deserve' anything, review or don't review, it is
completely up to everyone involved.

Believe me when I say we are perfectly capable of supporting our
constituencies without contributing a single line of code or comment
back to the good of the Linux security commons.

Our aggravation in all of this is when statements are made regarding
serious and supposedly well understood flaws in our approach that
'everyone' agrees to be the case.  Statements that are a complete and
utter crock of bullshit meant to simply gaslight the situation that
has gone down.

Hopefully our choice of lingua franca is sufficiently simple and
unsophisticated.

We would, again, encourage everyone to re-read our previous e-mail
where we outlined our concerns over the status of the review that did
occur.

We do respect reviewers, but let's engage in some sense of
intellectual honesty.  This is not a situation of some poor lonely
overworked individual reviewing Linux code in their mother's basement
at night in Gulley, Minnesota while they work at the Cenex Station
during the day.

Paul has publically stated that Microsoft employees him to maintain
the Linux security system because of Microsoft's concern for the long
term health and well being of Linux.  In case anyone doubts this or
missed it, here is the link:

https://lore.kernel.org/linux-security-module/20230608191304.253977-2-paul@paul-moore.com/

Unfortunately our experience seems to challenge Linus' mantra of:

"Code talks, bullshit walks".

Perhaps times have changed for Linux in this new custodial
environment.

> 1.	Lead with code. Save the documentation for later.
> 2.	Incremental implementation. Don't drop the whole mess on the
> 	reviewers at once. A patch set should be a story, with each patch
> 	introducing one new element.
> 3.	Emphasize the similarities with existing implementations. No one
> 	wants to deal with novel or clever code. If it is familiar, it is
> 	easy to understand.
> 4.	Thank your reviewers. Complaints about review latency typically
> 	increase it.
> 5.	Do some reviews yourself. That will get in the good graces of other
> 	reviewers.
> 6.	Be brief. The biggest single problem with reviewing TSEM has been that
> 	doing anything takes so long. Multiple paragraph responses to an issue
> 	don't help. Say it, say it once, say it in small words, and use as
> 	few of those as possible.

We appreciate the insight and recommendations, we will see how and
where all of this ends up getting litigated.

Given the zeal for simplicity embodied in these recommendations, we
will assume that adversaries targeting Linux from a security
perspective will also choose to limit themselves to simple and
unsophisticated means and methods of attack.

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project