All of lore.kernel.org
 help / color / mirror / Atom feed
From: akpm@linux-foundation.org (Andrew Morton)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.
Date: Tue, 3 Nov 2015 17:31:56 -0800	[thread overview]
Message-ID: <20151103173156.9ca17f52.akpm@linux-foundation.org> (raw)
In-Reply-To: <87k2pyppfk.fsf@x220.int.ebiederm.org>

On Tue, 03 Nov 2015 18:40:31 -0600 ebiederm at xmission.com (Eric W. Biederman) wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue,  3 Nov 2015 10:10:03 -0800 Daniel Cashman <dcashman@android.com> wrote:
> >
> >> ASLR currently only uses 8 bits to generate the random offset for the
> >> mmap base address on 32 bit architectures. This value was chosen to
> >> prevent a poorly chosen value from dividing the address space in such
> >> a way as to prevent large allocations. This may not be an issue on all
> >> platforms. Allow the specification of a minimum number of bits so that
> >> platforms desiring greater ASLR protection may determine where to place
> >> the trade-off.
> >
> > Can we please include a very good description of the motivation for this
> > change?  What is inadequate about the current code, what value does the
> > enhancement have to our users, what real-world problems are being solved,
> > etc.
> >
> > Because all we have at present is "greater ASLR protection", which doesn't
> > really tell anyone anything.
> 
> The description seemed clear to me.
> 
> More random bits, more entropy, more work needed to brute force.
> 
> 8 bits only requires 256 tries (or a 1 in 256) chance to brute force
> something.

Of course, but that's not really very useful.

> We have seen in the last couple of months on Android how only having 8 bits
> doesn't help much.

Now THAT is important.  What happened here and how well does the
proposed fix improve things?  How much longer will a brute-force attack
take to succeed, with a particular set of kernel parameters?  Is the
new duration considered to be sufficiently long and if not, are there
alternative fixes we should be looking at?

Stuff like this.

> Each additional bit doubles the protection (and unfortunately also
> increases fragmentation of the userspace address space).

OK, so the benefit comes with a cost and people who are configuring
systems (and the people who are reviewing this patchset!) need to
understand the tradeoffs.  Please.

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Daniel Cashman <dcashman@android.com>,
	linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	keescook@chromium.org, mingo@kernel.org,
	linux-arm-kernel@lists.infradead.org, corbet@lwn.net,
	dzickus@redhat.com, xypron.glpk@gmx.de, jpoimboe@redhat.com,
	kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com,
	aarcange@redhat.com, mgorman@suse.de, tglx@linutronix.de,
	rientjes@google.com, linux-mm@kvack.org,
	linux-doc@vger.kernel.org, salyzyn@android.com, jeffv@google.com,
	nnk@google.com, dcashman <dcashman@google.com>
Subject: Re: [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.
Date: Tue, 3 Nov 2015 17:31:56 -0800	[thread overview]
Message-ID: <20151103173156.9ca17f52.akpm@linux-foundation.org> (raw)
In-Reply-To: <87k2pyppfk.fsf@x220.int.ebiederm.org>

On Tue, 03 Nov 2015 18:40:31 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue,  3 Nov 2015 10:10:03 -0800 Daniel Cashman <dcashman@android.com> wrote:
> >
> >> ASLR currently only uses 8 bits to generate the random offset for the
> >> mmap base address on 32 bit architectures. This value was chosen to
> >> prevent a poorly chosen value from dividing the address space in such
> >> a way as to prevent large allocations. This may not be an issue on all
> >> platforms. Allow the specification of a minimum number of bits so that
> >> platforms desiring greater ASLR protection may determine where to place
> >> the trade-off.
> >
> > Can we please include a very good description of the motivation for this
> > change?  What is inadequate about the current code, what value does the
> > enhancement have to our users, what real-world problems are being solved,
> > etc.
> >
> > Because all we have at present is "greater ASLR protection", which doesn't
> > really tell anyone anything.
> 
> The description seemed clear to me.
> 
> More random bits, more entropy, more work needed to brute force.
> 
> 8 bits only requires 256 tries (or a 1 in 256) chance to brute force
> something.

Of course, but that's not really very useful.

> We have seen in the last couple of months on Android how only having 8 bits
> doesn't help much.

Now THAT is important.  What happened here and how well does the
proposed fix improve things?  How much longer will a brute-force attack
take to succeed, with a particular set of kernel parameters?  Is the
new duration considered to be sufficiently long and if not, are there
alternative fixes we should be looking at?

Stuff like this.

> Each additional bit doubles the protection (and unfortunately also
> increases fragmentation of the userspace address space).

OK, so the benefit comes with a cost and people who are configuring
systems (and the people who are reviewing this patchset!) need to
understand the tradeoffs.  Please.

--
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: Andrew Morton <akpm@linux-foundation.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Daniel Cashman <dcashman@android.com>,
	linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	keescook@chromium.org, mingo@kernel.org,
	linux-arm-kernel@lists.infradead.org, corbet@lwn.net,
	dzickus@redhat.com, xypron.glpk@gmx.de, jpoimboe@redhat.com,
	kirill.shutemov@linux.intel.com, n-horiguchi@ah.jp.nec.com,
	aarcange@redhat.com, mgorman@suse.de, tglx@linutronix.de,
	rientjes@google.com, linux-mm@kvack.org,
	linux-doc@vger.kernel.org, salyzyn@android.com, jeffv@google.com,
	nnk@google.com, dcashman <dcashman@google.com>
Subject: Re: [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.
Date: Tue, 3 Nov 2015 17:31:56 -0800	[thread overview]
Message-ID: <20151103173156.9ca17f52.akpm@linux-foundation.org> (raw)
In-Reply-To: <87k2pyppfk.fsf@x220.int.ebiederm.org>

On Tue, 03 Nov 2015 18:40:31 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote:

> Andrew Morton <akpm@linux-foundation.org> writes:
> 
> > On Tue,  3 Nov 2015 10:10:03 -0800 Daniel Cashman <dcashman@android.com> wrote:
> >
> >> ASLR currently only uses 8 bits to generate the random offset for the
> >> mmap base address on 32 bit architectures. This value was chosen to
> >> prevent a poorly chosen value from dividing the address space in such
> >> a way as to prevent large allocations. This may not be an issue on all
> >> platforms. Allow the specification of a minimum number of bits so that
> >> platforms desiring greater ASLR protection may determine where to place
> >> the trade-off.
> >
> > Can we please include a very good description of the motivation for this
> > change?  What is inadequate about the current code, what value does the
> > enhancement have to our users, what real-world problems are being solved,
> > etc.
> >
> > Because all we have at present is "greater ASLR protection", which doesn't
> > really tell anyone anything.
> 
> The description seemed clear to me.
> 
> More random bits, more entropy, more work needed to brute force.
> 
> 8 bits only requires 256 tries (or a 1 in 256) chance to brute force
> something.

Of course, but that's not really very useful.

> We have seen in the last couple of months on Android how only having 8 bits
> doesn't help much.

Now THAT is important.  What happened here and how well does the
proposed fix improve things?  How much longer will a brute-force attack
take to succeed, with a particular set of kernel parameters?  Is the
new duration considered to be sufficiently long and if not, are there
alternative fixes we should be looking at?

Stuff like this.

> Each additional bit doubles the protection (and unfortunately also
> increases fragmentation of the userspace address space).

OK, so the benefit comes with a cost and people who are configuring
systems (and the people who are reviewing this patchset!) need to
understand the tradeoffs.  Please.

  reply	other threads:[~2015-11-04  1:31 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 18:10 [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR Daniel Cashman
2015-11-03 18:10 ` Daniel Cashman
2015-11-03 18:10 ` Daniel Cashman
2015-11-03 18:10 ` [PATCH v2 2/2] arm: mm: support ARCH_MMAP_RND_BITS Daniel Cashman
2015-11-03 18:10   ` Daniel Cashman
2015-11-03 18:10   ` Daniel Cashman
2015-11-03 19:19   ` Kees Cook
2015-11-03 19:19     ` Kees Cook
2015-11-03 19:19     ` Kees Cook
2015-11-03 22:39     ` Russell King - ARM Linux
2015-11-03 22:39       ` Russell King - ARM Linux
2015-11-03 22:39       ` Russell King - ARM Linux
2015-11-03 23:18       ` Kees Cook
2015-11-03 23:18         ` Kees Cook
2015-11-03 23:18         ` Kees Cook
2015-11-04 18:22         ` Daniel Cashman
2015-11-04 18:22           ` Daniel Cashman
2015-11-04 18:22           ` Daniel Cashman
2015-11-03 23:14     ` Daniel Cashman
2015-11-03 23:14       ` Daniel Cashman
2015-11-03 23:14       ` Daniel Cashman
2015-11-03 23:21       ` Kees Cook
2015-11-03 23:21         ` Kees Cook
2015-11-03 23:21         ` Kees Cook
2015-11-04 18:30         ` Daniel Cashman
2015-11-04 18:30           ` Daniel Cashman
2015-11-04 18:30           ` Daniel Cashman
2015-11-05 18:44           ` Daniel Cashman
2015-11-05 18:44             ` Daniel Cashman
2015-11-05 18:44             ` Daniel Cashman
2015-11-06 20:52             ` Kees Cook
2015-11-06 20:52               ` Kees Cook
2015-11-06 20:52               ` Kees Cook
2015-11-09  3:47               ` Michael Ellerman
2015-11-09  3:47                 ` Michael Ellerman
2015-11-09  3:47                 ` Michael Ellerman
2015-11-09 18:56                 ` Daniel Cashman
2015-11-09 18:56                   ` Daniel Cashman
2015-11-09 18:56                   ` Daniel Cashman
2015-11-09 21:27                   ` Kees Cook
2015-11-09 21:27                     ` Kees Cook
2015-11-09 21:27                     ` Kees Cook
2015-11-03 19:16 ` [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR Kees Cook
2015-11-03 19:16   ` Kees Cook
2015-11-03 19:16   ` Kees Cook
2015-11-04  0:04 ` Andrew Morton
2015-11-04  0:04   ` Andrew Morton
2015-11-04  0:04   ` Andrew Morton
2015-11-04  0:40   ` Eric W. Biederman
2015-11-04  0:40     ` Eric W. Biederman
2015-11-04  0:40     ` Eric W. Biederman
2015-11-04  1:31     ` Andrew Morton [this message]
2015-11-04  1:31       ` Andrew Morton
2015-11-04  1:31       ` Andrew Morton
2015-11-04 19:31       ` Daniel Cashman
2015-11-04 19:31         ` Daniel Cashman
2015-11-04 19:31         ` Daniel Cashman
2015-11-04 22:00         ` Andrew Morton
2015-11-04 22:00           ` Andrew Morton
2015-11-04 22:00           ` Andrew Morton
2015-11-04 22:10         ` Eric W. Biederman
2015-11-04 22:10           ` Eric W. Biederman
2015-11-04 22:10           ` Eric W. Biederman
2015-11-04 22:37           ` Kees Cook
2015-11-04 22:37             ` Kees Cook
2015-11-04 22:37             ` Kees Cook
2015-11-04  9:39 ` Michal Hocko
2015-11-04  9:39   ` Michal Hocko
2015-11-04  9:39   ` Michal Hocko
2015-11-04 19:21   ` Eric W. Biederman
2015-11-04 19:21     ` Eric W. Biederman
2015-11-04 19:21     ` Eric W. Biederman
2015-11-04 19:36     ` Daniel Cashman
2015-11-04 19:36       ` Daniel Cashman
2015-11-04 19:36       ` Daniel Cashman

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=20151103173156.9ca17f52.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-arm-kernel@lists.infradead.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.