From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>, Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Laura Abbott <labbott@redhat.com>,
Daniel Micay <danielmicay@gmail.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Helge Deller <deller@gmx.de>, LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation
Date: Thu, 29 Jun 2017 13:54:13 -0400 [thread overview]
Message-ID: <1498758853.6130.2.camel@redhat.com> (raw)
In-Reply-To: <CAGXu5jLLFKnboaLJKGcGT-Ra80ZzAf3jZ=zex6vd8uDQamBJxg@mail.gmail.com>
On Thu, 2017-06-29 at 10:47 -0700, Kees Cook wrote:
> On Thu, Jun 29, 2017 at 10:05 AM, Christoph Lameter <cl@linux.com>
> wrote:
> > On Sun, 25 Jun 2017, Kees Cook wrote:
> >
> > > The difference gets lost in the noise, but if the above is
> > > sensible,
> > > it's 0.07% slower. ;)
> >
> > Hmmm... These differences add up. Also in a repetative benchmark
> > like that
> > you do not see the impact that the additional cacheline use in the
> > cpu
> > cache has on larger workloads. Those may be pushed over the edge of
> > l1 or
> > l2 capacity at some point which then causes drastic regressions.
>
> Even if that is true, it may be worth it to some people to have the
> protection. Given that is significantly hampers a large class of heap
> overflow attacks[1], I think it's an important change to have. I'm
> not
> suggesting this be on by default, it's cleanly behind
> CONFIG-controlled macros, and is very limited in scope. If you can
> Ack
> it we can let system builders decide if they want to risk a possible
> performance hit. I'm pretty sure most distros would like to have this
> protection.
I could certainly see it being useful for all kinds of portable
and network-connected systems where security is simply much
more important than performance.
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>, Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Laura Abbott <labbott@redhat.com>,
Daniel Micay <danielmicay@gmail.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Helge Deller <deller@gmx.de>, LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation
Date: Thu, 29 Jun 2017 13:54:13 -0400 [thread overview]
Message-ID: <1498758853.6130.2.camel@redhat.com> (raw)
In-Reply-To: <CAGXu5jLLFKnboaLJKGcGT-Ra80ZzAf3jZ=zex6vd8uDQamBJxg@mail.gmail.com>
On Thu, 2017-06-29 at 10:47 -0700, Kees Cook wrote:
> On Thu, Jun 29, 2017 at 10:05 AM, Christoph Lameter <cl@linux.com>
> wrote:
> > On Sun, 25 Jun 2017, Kees Cook wrote:
> >
> > > The difference gets lost in the noise, but if the above is
> > > sensible,
> > > it's 0.07% slower. ;)
> >
> > Hmmm... These differences add up. Also in a repetative benchmark
> > like that
> > you do not see the impact that the additional cacheline use in the
> > cpu
> > cache has on larger workloads. Those may be pushed over the edge of
> > l1 or
> > l2 capacity at some point which then causes drastic regressions.
>
> Even if that is true, it may be worth it to some people to have the
> protection. Given that is significantly hampers a large class of heap
> overflow attacks[1], I think it's an important change to have. I'm
> not
> suggesting this be on by default, it's cleanly behind
> CONFIG-controlled macros, and is very limited in scope. If you can
> Ack
> it we can let system builders decide if they want to risk a possible
> performance hit. I'm pretty sure most distros would like to have this
> protection.
I could certainly see it being useful for all kinds of portable
and network-connected systems where security is simply much
more important than performance.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Rik van Riel <riel@redhat.com>
To: Kees Cook <keescook@chromium.org>, Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Laura Abbott <labbott@redhat.com>,
Daniel Micay <danielmicay@gmail.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Andy Lutomirski <luto@kernel.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Tejun Heo <tj@kernel.org>, Daniel Mack <daniel@zonque.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Helge Deller <deller@gmx.de>, LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation
Date: Thu, 29 Jun 2017 13:54:13 -0400 [thread overview]
Message-ID: <1498758853.6130.2.camel@redhat.com> (raw)
In-Reply-To: <CAGXu5jLLFKnboaLJKGcGT-Ra80ZzAf3jZ=zex6vd8uDQamBJxg@mail.gmail.com>
On Thu, 2017-06-29 at 10:47 -0700, Kees Cook wrote:
> On Thu, Jun 29, 2017 at 10:05 AM, Christoph Lameter <cl@linux.com>
> wrote:
> > On Sun, 25 Jun 2017, Kees Cook wrote:
> >
> > > The difference gets lost in the noise, but if the above is
> > > sensible,
> > > it's 0.07% slower. ;)
> >
> > Hmmm... These differences add up. Also in a repetative benchmark
> > like that
> > you do not see the impact that the additional cacheline use in the
> > cpu
> > cache has on larger workloads. Those may be pushed over the edge of
> > l1 or
> > l2 capacity at some point which then causes drastic regressions.
>
> Even if that is true, it may be worth it to some people to have the
> protection. Given that is significantly hampers a large class of heap
> overflow attacks[1], I think it's an important change to have. I'm
> not
> suggesting this be on by default, it's cleanly behind
> CONFIG-controlled macros, and is very limited in scope. If you can
> Ack
> it we can let system builders decide if they want to risk a possible
> performance hit. I'm pretty sure most distros would like to have this
> protection.
I could certainly see it being useful for all kinds of portable
and network-connected systems where security is simply much
more important than performance.
next prev parent reply other threads:[~2017-06-29 17:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-23 1:50 [kernel-hardening] [PATCH v2] mm: Add SLUB free list pointer obfuscation Kees Cook
2017-06-23 1:50 ` Kees Cook
2017-06-23 1:50 ` Kees Cook
2017-06-25 19:56 ` [kernel-hardening] " Kees Cook
2017-06-25 19:56 ` Kees Cook
2017-06-25 19:56 ` Kees Cook
2017-06-29 17:05 ` [kernel-hardening] " Christoph Lameter
2017-06-29 17:05 ` Christoph Lameter
2017-06-29 17:05 ` Christoph Lameter
2017-06-29 17:47 ` [kernel-hardening] " Kees Cook
2017-06-29 17:47 ` Kees Cook
2017-06-29 17:47 ` Kees Cook
2017-06-29 17:54 ` Rik van Riel [this message]
2017-06-29 17:54 ` Rik van Riel
2017-06-29 17:54 ` Rik van Riel
2017-06-29 17:56 ` [kernel-hardening] " Tycho Andersen
2017-06-29 17:56 ` Tycho Andersen
2017-07-05 23:30 ` Kees Cook
2017-07-05 23:30 ` Kees Cook
2017-07-05 23:39 ` Andrew Morton
2017-07-05 23:39 ` Andrew Morton
2017-07-05 23:39 ` Andrew Morton
2017-07-05 23:56 ` [kernel-hardening] " Kees Cook
2017-07-05 23:56 ` Kees Cook
2017-07-05 23:56 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1498758853.6130.2.camel@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=cl@linux.com \
--cc=daniel@zonque.org \
--cc=danielmicay@gmail.com \
--cc=deller@gmx.de \
--cc=iamjoonsoo.kim@lge.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.