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
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
[ 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
[ 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
[ 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
[ 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
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?"
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?"
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
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
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
>
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
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?
>
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
32 matches
Mail list logo