lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2017-11-21 00:29    [W:0.063 / U:2.212 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site