linux-kernel - Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

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]

Date:   Tue, 21 Nov 2017 14:53:48 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Kees Cook <keescook@...omium.org>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        Linus Torvalds <torvalds@...uxfoundation.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Windsor <dave@...gbits.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Subject: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

On Mon, Nov 20, 2017 at 04:42:46PM -0800, Kees Cook wrote:
> I'm always trying to balance the requests from both ends of the
> security defense spectrum. One of the most common requests I get from
> people who are strongly interested in the defenses is "can this please
> be enabled by default?" And then I have to explain that it sometimes
> takes time for code to shake out, and it sometimes takes time for
> developers to trust it, etc. This is rarely a comfort to them, but
> they tend to be glad they can turn some config knob to enable the
> "strongest" version, etc, because for them, a false positive is no big
> deal. At the other end is the requirement that new stuff should not
> break the system. Both are reasonable perspectives, but if we violate
> the latter, the defense will never end up in the kernel in the first
> place.

I think Linus' objections must be seen in a broader context,
the last months we've seen a large influx of semi-automatically
generated hardening patches (constification mostly);  The volume
of these was at times overwhelming, in some cases they were dropped
on the mailing lists in a fire-and-forget fashion and there are
multiple documented cases where these patches broke things and the
community was left to repair the fallout.

When LWN published the 4.14 patch statistics (which some contributors
seem to mistake for a high score), Alexandre Belloni (+cc) rightfully
raised a complaint and included links to some of the broken patches:

https://lwn.net/Articles/736578/#CommAnchor737081

There is a growing sense that hardening patches (which are generally
desirable of course) are forced into the kernel without due diligence.
Objections against tone notwithstanding, making that concern known in
a form with greater visibility than an LWN comment was appropriate by
Linus.

It is most unfortunate that these concerns happened to be adressed to
you personally and stalled your patches (the quality of which I cannot
judge), even though they must (in my opinion) be interpreted in the
context of this larger issue.

It is likewise most unfortunate that this allowed bloggers, journalists
and HN know-it-alls with zero commits in the kernel and zero participation
on the mailing lists to focus on tone and whatnot, but completely
ignore what this is really about.

Thanks,

Lukas