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

2017-11-21 Thread Randy Dunlap
On 11/21/2017 05:53 AM, Lukas Wunner wrote: > 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

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

2017-11-21 Thread Randy Dunlap
On 11/21/2017 05:53 AM, Lukas Wunner wrote: > 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

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

2017-11-21 Thread Linus Torvalds
[ This turned longer than it should have. I guess jet lag is a good thing ] On Tue, Nov 21, 2017 at 3:48 AM, Jason A. Donenfeld wrote: > > It might be news to you that actually some security people scoff at > other security peoples' obsession with "security bugs". Heh. I'm not

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

2017-11-21 Thread Linus Torvalds
[ This turned longer than it should have. I guess jet lag is a good thing ] On Tue, Nov 21, 2017 at 3:48 AM, Jason A. Donenfeld wrote: > > It might be news to you that actually some security people scoff at > other security peoples' obsession with "security bugs". Heh. I'm not actually

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

2017-11-21 Thread Linus Torvalds
[ this is just a resend of yesterday's mobile html version that got rejected by the lists, sorry for the duplication ] On Mon, Nov 20, 2017 at 9:50 AM, Matthew Garrett wrote: > > Can you clarify a little with regard to how you'd have liked this > patchset to look? So I

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

2017-11-21 Thread Linus Torvalds
[ this is just a resend of yesterday's mobile html version that got rejected by the lists, sorry for the duplication ] On Mon, Nov 20, 2017 at 9:50 AM, Matthew Garrett wrote: > > Can you clarify a little with regard to how you'd have liked this > patchset to look? So I think the actual status

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

2017-11-21 Thread Lukas Wunner
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?"

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

2017-11-21 Thread Lukas Wunner
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?"

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

2017-11-21 Thread Jason A. Donenfeld
Hi Linus, On Fri, Nov 17, 2017 at 10:13 PM, Linus Torvalds wrote: > As a security person, you need to repeat this mantra: > > "security problems are just bugs" > > and you need to _internalize_ it, instead of scoff at it. It might be news to you that actually

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

2017-11-21 Thread Jason A. Donenfeld
Hi Linus, On Fri, Nov 17, 2017 at 10:13 PM, Linus Torvalds wrote: > As a security person, you need to repeat this mantra: > > "security problems are just bugs" > > and you need to _internalize_ it, instead of scoff at it. It might be news to you that actually some security people scoff at

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

2017-11-20 Thread Kees Cook
On Mon, Nov 20, 2017 at 3:29 PM, Matthew Garrett wrote: > 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 >

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

2017-11-20 Thread Kees Cook
On Mon, Nov 20, 2017 at 3:29 PM, Matthew Garrett wrote: > 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

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

2017-11-20 Thread Matthew Garrett
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" wrote: > > >> Can you clarify a little with regard to how you'd have liked this >> patchset to look? > > >

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

2017-11-20 Thread Matthew Garrett
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" wrote: > > >> Can you clarify a little with regard to how you'd have liked this >> patchset to look? > > > So I think the actual

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

2017-11-20 Thread Matthew Garrett
On Fri, Nov 17, 2017 at 01:13:10PM -0800, Linus Torvalds wrote: > So the hardening efforts should instead _start_ from the standpoint of > "let's warn about what looks dangerous, and maybe in a _year_ when > we've warned for a long time, and we are confident that we've actually > caught all the

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

2017-11-20 Thread Matthew Garrett
On Fri, Nov 17, 2017 at 01:13:10PM -0800, Linus Torvalds wrote: > So the hardening efforts should instead _start_ from the standpoint of > "let's warn about what looks dangerous, and maybe in a _year_ when > we've warned for a long time, and we are confident that we've actually > caught all the

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

2017-11-17 Thread Kees Cook
On Fri, Nov 17, 2017 at 1:13 PM, Linus Torvalds wrote: > As long as you see your hardening efforts primarily as a "let me kill > the machine/process on bad behavior", I will stop taking those shit > patches. Yes, this is entirely clear. This is why I adjusted this

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

2017-11-17 Thread Kees Cook
On Fri, Nov 17, 2017 at 1:13 PM, Linus Torvalds wrote: > As long as you see your hardening efforts primarily as a "let me kill > the machine/process on bad behavior", I will stop taking those shit > patches. Yes, this is entirely clear. This is why I adjusted this series (in multiple places) to

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

2017-11-17 Thread Linus Torvalds
On Fri, Nov 17, 2017 at 12:35 PM, Kees Cook wrote: > > This is why I introduced the fallback mode: with both kvm and sctp > (ipv6) not noticed until late in the development cycle, I became much > less satisfied it had gotten sufficient testing. So honestly, this is the

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

2017-11-17 Thread Linus Torvalds
On Fri, Nov 17, 2017 at 12:35 PM, Kees Cook wrote: > > This is why I introduced the fallback mode: with both kvm and sctp > (ipv6) not noticed until late in the development cycle, I became much > less satisfied it had gotten sufficient testing. So honestly, this is the kind of completely

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

2017-11-17 Thread Kees Cook
On Fri, Nov 17, 2017 at 9:45 AM, Paolo Bonzini wrote: > On 17/11/2017 18:35, Linus Torvalds wrote: >> Honestly, I'm unlikely to pull this at all this merge window, simply >> because I won't have time for it. This merge window is not going to be >> one where I can take a

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

2017-11-17 Thread Kees Cook
On Fri, Nov 17, 2017 at 9:45 AM, Paolo Bonzini wrote: > On 17/11/2017 18:35, Linus Torvalds wrote: >> Honestly, I'm unlikely to pull this at all this merge window, simply >> because I won't have time for it. This merge window is not going to be >> one where I can take a leisurely look at

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

2017-11-17 Thread Paolo Bonzini
On 17/11/2017 18:35, Linus Torvalds wrote: > Honestly, I'm unlikely to pull this at all this merge window, simply > because I won't have time for it. This merge window is not going to be > one where I can take a leisurely look at something like this. > > If you can make a smaller pull request

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

2017-11-17 Thread Paolo Bonzini
On 17/11/2017 18:35, Linus Torvalds wrote: > Honestly, I'm unlikely to pull this at all this merge window, simply > because I won't have time for it. This merge window is not going to be > one where I can take a leisurely look at something like this. > > If you can make a smaller pull request

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

2017-11-17 Thread Linus Torvalds
On Fri, Nov 17, 2017 at 8:54 AM, Kees Cook wrote: > > (Sorry if this pull request is a duplicate: I just don't want to miss > the merge window, given its potential for being shorter than usual.) Honestly, these things always end up waiting to the end for me, simply because

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

2017-11-17 Thread Linus Torvalds
On Fri, Nov 17, 2017 at 8:54 AM, Kees Cook wrote: > > (Sorry if this pull request is a duplicate: I just don't want to miss > the merge window, given its potential for being shorter than usual.) Honestly, these things always end up waiting to the end for me, simply because they are scary, and I

[GIT PULL] usercopy whitelisting for v4.15-rc1

2017-11-17 Thread Kees Cook
Hi Linus, Please pull these hardened usercopy changes for v4.15-rc1. This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs by adding explicit whitelisting for slab cache regions. This has lived in -next for quite some time without major

[GIT PULL] usercopy whitelisting for v4.15-rc1

2017-11-17 Thread Kees Cook
Hi Linus, Please pull these hardened usercopy changes for v4.15-rc1. This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs by adding explicit whitelisting for slab cache regions. This has lived in -next for quite some time without major

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

2017-11-15 Thread Kees Cook
On Sun, Nov 12, 2017 at 11:29 PM, Kees Cook wrote: > Please pull these hardened usercopy whitelisting changes for v4.15-rc1. > This significantly narrows the areas of memory that can be copied to/from > userspace in the face of usercopy bugs. Just wanted to make sure this

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

2017-11-15 Thread Kees Cook
On Sun, Nov 12, 2017 at 11:29 PM, Kees Cook wrote: > Please pull these hardened usercopy whitelisting changes for v4.15-rc1. > This significantly narrows the areas of memory that can be copied to/from > userspace in the face of usercopy bugs. Just wanted to make sure this pull request was still

[GIT PULL] usercopy whitelisting for v4.15-rc1

2017-11-12 Thread Kees Cook
Hi, Please pull these hardened usercopy whitelisting changes for v4.15-rc1. This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs. Thanks! -Kees The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux

[GIT PULL] usercopy whitelisting for v4.15-rc1

2017-11-12 Thread Kees Cook
Hi, Please pull these hardened usercopy whitelisting changes for v4.15-rc1. This significantly narrows the areas of memory that can be copied to/from userspace in the face of usercopy bugs. Thanks! -Kees The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff: Linux