From: ebiederm@xmission.com (Eric W. Biederman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] mm: mmap: Add new /proc tunable for mmap_base ASLR.
Date: Tue, 03 Nov 2015 18:40:31 -0600 [thread overview]
Message-ID: <87k2pyppfk.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20151103160410.34bbebc805c17d2f41150a19@linux-foundation.org> (Andrew Morton's message of "Tue, 3 Nov 2015 16:04:10 -0800")
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.
We have seen in the last couple of months on Android how only having 8 bits
doesn't help much.
Each additional bit doubles the protection (and unfortunately also
increases fragmentation of the userspace address space).
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
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, 03 Nov 2015 18:40:31 -0600 [thread overview]
Message-ID: <87k2pyppfk.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20151103160410.34bbebc805c17d2f41150a19@linux-foundation.org> (Andrew Morton's message of "Tue, 3 Nov 2015 16:04:10 -0800")
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.
We have seen in the last couple of months on Android how only having 8 bits
doesn't help much.
Each additional bit doubles the protection (and unfortunately also
increases fragmentation of the userspace address space).
Eric
--
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: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@linux-foundation.org>
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, 03 Nov 2015 18:40:31 -0600 [thread overview]
Message-ID: <87k2pyppfk.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20151103160410.34bbebc805c17d2f41150a19@linux-foundation.org> (Andrew Morton's message of "Tue, 3 Nov 2015 16:04:10 -0800")
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.
We have seen in the last couple of months on Android how only having 8 bits
doesn't help much.
Each additional bit doubles the protection (and unfortunately also
increases fragmentation of the userspace address space).
Eric
next prev parent reply other threads:[~2015-11-04 0:40 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 [this message]
2015-11-04 0:40 ` Eric W. Biederman
2015-11-04 0:40 ` Eric W. Biederman
2015-11-04 1:31 ` Andrew Morton
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=87k2pyppfk.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--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.