Date Mon, 20 Nov 2017 23:29:37 +0000 From Matthew Garrett <> 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@srcf.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@srcf.ucam.org



