All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Cooper <jason@lakedaemon.net>
To: "Roberts, William C" <william.c.roberts@intel.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"nnk@google.com" <nnk@google.com>,
	"jeffv@google.com" <jeffv@google.com>,
	"salyzyn@android.com" <salyzyn@android.com>,
	"dcashman@android.com" <dcashman@android.com>
Subject: Re: [PATCH] [RFC] Introduce mmap randomization
Date: Tue, 26 Jul 2016 20:59:44 +0000	[thread overview]
Message-ID: <20160726205944.GM4541@io.lakedaemon.net> (raw)
In-Reply-To: <476DC76E7D1DF2438D32BFADF679FC560125F29C@ORSMSX103.amr.corp.intel.com>

Hi William,

On Tue, Jul 26, 2016 at 08:13:23PM +0000, Roberts, William C wrote:
> > > From: Jason Cooper [mailto:jason@lakedaemon.net]
> > > On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.roberts@intel.com wrote:
> > > > Performance Measurements:
> > > > Using strace with -T option and filtering for mmap on the program ls
> > > > shows a slowdown of approximate 3.7%
> > >
> > > I think it would be helpful to show the effect on the resulting object code.
> > 
> > Do you mean the maps of the process? I have some captures for whoopsie on my
> > Ubuntu system I can share.

No, I mean changes to mm/mmap.o.

> > One thing I didn't make clear in my commit message is why this is good. Right
> > now, if you know An address within in a process, you know all offsets done with
> > mmap(). For instance, an offset To libX can yield libY by adding/subtracting an
> > offset. This is meant to make rops a bit harder, or In general any mapping offset
> > mmore difficult to find/guess.

Are you able to quantify how many bits of entropy you're imposing on the
attacker?  Is this a chair in the hallway or a significant increase in
the chances of crashing the program before finding the desired address?

thx,

Jason.

WARNING: multiple messages have this Message-ID (diff)
From: Jason Cooper <jason@lakedaemon.net>
To: "Roberts, William C" <william.c.roberts@intel.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"nnk@google.com" <nnk@google.com>,
	"jeffv@google.com" <jeffv@google.com>,
	"salyzyn@android.com" <salyzyn@android.com>,
	"dcashman@android.com" <dcashman@android.com>
Subject: Re: [PATCH] [RFC] Introduce mmap randomization
Date: Tue, 26 Jul 2016 20:59:44 +0000	[thread overview]
Message-ID: <20160726205944.GM4541@io.lakedaemon.net> (raw)
In-Reply-To: <476DC76E7D1DF2438D32BFADF679FC560125F29C@ORSMSX103.amr.corp.intel.com>

Hi William,

On Tue, Jul 26, 2016 at 08:13:23PM +0000, Roberts, William C wrote:
> > > From: Jason Cooper [mailto:jason@lakedaemon.net]
> > > On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.roberts@intel.com wrote:
> > > > Performance Measurements:
> > > > Using strace with -T option and filtering for mmap on the program ls
> > > > shows a slowdown of approximate 3.7%
> > >
> > > I think it would be helpful to show the effect on the resulting object code.
> > 
> > Do you mean the maps of the process? I have some captures for whoopsie on my
> > Ubuntu system I can share.

No, I mean changes to mm/mmap.o.

> > One thing I didn't make clear in my commit message is why this is good. Right
> > now, if you know An address within in a process, you know all offsets done with
> > mmap(). For instance, an offset To libX can yield libY by adding/subtracting an
> > offset. This is meant to make rops a bit harder, or In general any mapping offset
> > mmore difficult to find/guess.

Are you able to quantify how many bits of entropy you're imposing on the
attacker?  Is this a chair in the hallway or a significant increase in
the chances of crashing the program before finding the desired address?

thx,

Jason.

--
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: Jason Cooper <jason@lakedaemon.net>
To: "Roberts, William C" <william.c.roberts@intel.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"nnk@google.com" <nnk@google.com>,
	"jeffv@google.com" <jeffv@google.com>,
	"salyzyn@android.com" <salyzyn@android.com>,
	"dcashman@android.com" <dcashman@android.com>
Subject: [kernel-hardening] Re: [PATCH] [RFC] Introduce mmap randomization
Date: Tue, 26 Jul 2016 20:59:44 +0000	[thread overview]
Message-ID: <20160726205944.GM4541@io.lakedaemon.net> (raw)
In-Reply-To: <476DC76E7D1DF2438D32BFADF679FC560125F29C@ORSMSX103.amr.corp.intel.com>

Hi William,

On Tue, Jul 26, 2016 at 08:13:23PM +0000, Roberts, William C wrote:
> > > From: Jason Cooper [mailto:jason@lakedaemon.net]
> > > On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.roberts@intel.com wrote:
> > > > Performance Measurements:
> > > > Using strace with -T option and filtering for mmap on the program ls
> > > > shows a slowdown of approximate 3.7%
> > >
> > > I think it would be helpful to show the effect on the resulting object code.
> > 
> > Do you mean the maps of the process? I have some captures for whoopsie on my
> > Ubuntu system I can share.

No, I mean changes to mm/mmap.o.

> > One thing I didn't make clear in my commit message is why this is good. Right
> > now, if you know An address within in a process, you know all offsets done with
> > mmap(). For instance, an offset To libX can yield libY by adding/subtracting an
> > offset. This is meant to make rops a bit harder, or In general any mapping offset
> > mmore difficult to find/guess.

Are you able to quantify how many bits of entropy you're imposing on the
attacker?  Is this a chair in the hallway or a significant increase in
the chances of crashing the program before finding the desired address?

thx,

Jason.

  reply	other threads:[~2016-07-26 21:00 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26 18:22 [PATCH] [RFC] Introduce mmap randomization william.c.roberts
2016-07-26 18:22 ` [kernel-hardening] " william.c.roberts
2016-07-26 18:22 ` william.c.roberts
2016-07-26 18:22   ` [kernel-hardening] " william.c.roberts
2016-07-26 20:03   ` Jason Cooper
2016-07-26 20:03     ` [kernel-hardening] " Jason Cooper
2016-07-26 20:11     ` Roberts, William C
2016-07-26 20:11       ` [kernel-hardening] " Roberts, William C
2016-07-26 20:13     ` Roberts, William C
2016-07-26 20:13       ` [kernel-hardening] " Roberts, William C
2016-07-26 20:13       ` Roberts, William C
2016-07-26 20:59       ` Jason Cooper [this message]
2016-07-26 20:59         ` [kernel-hardening] " Jason Cooper
2016-07-26 20:59         ` Jason Cooper
2016-07-26 21:06         ` Roberts, William C
2016-07-26 21:06           ` [kernel-hardening] " Roberts, William C
2016-07-26 21:06           ` Roberts, William C
2016-07-26 21:44           ` Jason Cooper
2016-07-26 21:44             ` [kernel-hardening] " Jason Cooper
2016-07-26 21:44             ` Jason Cooper
2016-07-26 23:51             ` Dave Hansen
2016-07-26 23:51               ` [kernel-hardening] " Dave Hansen
2016-07-26 23:51               ` Dave Hansen
2016-08-02 17:17             ` Roberts, William C
2016-08-02 17:17               ` [kernel-hardening] " Roberts, William C
2016-08-02 17:17               ` Roberts, William C
2016-08-03 18:19               ` Roberts, William C
2016-08-03 18:19                 ` [kernel-hardening] " Roberts, William C
2016-08-03 18:19                 ` Roberts, William C
2016-08-02 17:15           ` Roberts, William C
2016-08-02 17:15             ` [kernel-hardening] " Roberts, William C
2016-08-02 17:15             ` Roberts, William C
2016-07-27 16:59         ` Nick Kralevich
2016-07-27 16:59           ` [kernel-hardening] " Nick Kralevich
2016-07-27 16:59           ` Nick Kralevich
2016-07-28 21:07           ` Jason Cooper
2016-07-28 21:07             ` [kernel-hardening] " Jason Cooper
2016-07-28 21:07             ` Jason Cooper
2016-07-29 10:10             ` [kernel-hardening] " Daniel Micay
2016-07-31 22:24               ` Jason Cooper
2016-07-31 22:24                 ` Jason Cooper
2016-08-01  0:24                 ` Daniel Micay
2016-08-02 16:57           ` Roberts, William C
2016-08-02 16:57             ` [kernel-hardening] " Roberts, William C
2016-08-02 16:57             ` Roberts, William C
2016-08-02 17:02             ` Nick Kralevich
2016-08-02 17:02               ` [kernel-hardening] " Nick Kralevich
2016-08-02 17:02               ` Nick Kralevich
2016-08-14 16:31           ` Pavel Machek 1
2016-08-14 16:31             ` [kernel-hardening] " Pavel Machek 1
2016-08-14 16:31             ` Pavel Machek 1
2016-07-26 20:12   ` [kernel-hardening] " Rik van Riel
2016-07-26 20:17     ` Roberts, William C
2016-07-26 20:17       ` Roberts, William C
2016-07-26 20:17       ` Roberts, William C
2016-07-26 20:41   ` Nick Kralevich
2016-07-26 20:41     ` [kernel-hardening] " Nick Kralevich
2016-07-26 21:02     ` Roberts, William C
2016-07-26 21:02       ` [kernel-hardening] " Roberts, William C
2016-07-26 21:11       ` Nick Kralevich
2016-07-26 21:11         ` [kernel-hardening] " Nick Kralevich
2016-07-26 21:11         ` Nick Kralevich
2016-08-14 16:22   ` Pavel Machek
2016-08-14 16:22     ` [kernel-hardening] " Pavel Machek
2016-08-04 16:53 ` [kernel-hardening] " Daniel Micay
2016-08-04 16:55   ` Roberts, William C
2016-08-04 16:55     ` Roberts, William C
2016-08-04 17:10     ` Daniel Micay
2016-07-26 18:27 william.c.roberts
2016-07-26 19:26 ` Kirill A. Shutemov
2016-07-26 19:57   ` Roberts, William C
2016-07-26 20:29     ` Kirill A. Shutemov
2016-07-26 20:35       ` Roberts, William C

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=20160726205944.GM4541@io.lakedaemon.net \
    --to=jason@lakedaemon.net \
    --cc=akpm@linux-foundation.org \
    --cc=dcashman@android.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeffv@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nnk@google.com \
    --cc=salyzyn@android.com \
    --cc=william.c.roberts@intel.com \
    /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.