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-next>] [day] [month] [year] [list]

Date:   Mon, 20 Nov 2017 23:29:37 +0000
From:   Matthew Garrett <mjg59@...f.ucam.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Kees Cook <keescook@...omium.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        David Windsor <dave@...lcore.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] usercopy whitelisting for v4.15-rc1

On Mon, Nov 20, 2017 at 12:47:10PM -1000, Linus Torvalds wrote:
> Sorry, on mobile right now, thus nasty HTML email..
> 
> On Nov 20, 2017 09:50, "Matthew Garrett" <mjg59@...f.ucam.org> wrote:
> 
> 
>> Can you clarify a little with regard to how you'd have liked this
>> patchset to look?
> 
> 
> So I think the actual status of the patches is fairly good with the default
> warning.
> 
> But what I'd really like to see is to not have to worry so much about these
> hardening things. The last set of user access hardening really was more
> painful than it might have been.

Sure, and Kees learned from that experience and added the default 
fallback in response to it. Let's reward people for learning from past 
problems rather than screaming at them :)

>From a practical perspective this does feel like a completely reasonable 
request - when changing the semantics of kernel APIs in ways that aren't 
amenable to automated analysis, doing so in a way that generates 
warnings rather than triggering breakage is pretty clearly a preferable 
approach. But these features often start off seeming simple and then 
devolving into rounds of "ok just one more fix and we'll have 
everything" and by then it's easy to have lost track of the amount of 
complexity that's developed as a result. Formalising the Right Way of 
approaching these problems would possibly help avoid this kind of 
problem in future - I'll try to write something up for 
Documentation/process.

> And largely due to that I was really dreading pulling this one - and then
> with 20+ pulls a day because I really wanted to get everything big merged
> before travel, I basically ran out of time.
> 
> Part of that is probably also because the 4.15 merge window actually ended
> up bigger than I expected. I was perhaps naive, but I expected that because
> of 4.14 being LTS, this release would be smaller (like 4.9 vs 4.10) but
> that never happened.
> 
> So where I'd really like to be is simply that these pulls wouldn't be so
> nerve wracking for me. And that's largely me worrying about the approach
> people are taking, which is why I then reacted so strongly to the whole
> "warnings came later".
> 
> Sorry for the strong words.

This one seems unfortunate in that a lot of people interpreted it as 
"Kees submits bad code", and I think that does have an impact on 
people's enthusiasm for submitting more complex or controversial work. 
The number of people willing to work on security stuff is limited enough 
for various reasons, let's try to keep hold of the ones we have!

-- 
Matthew Garrett | mjg59@...f.ucam.org