[PATCH v2 2/2] arm: mm: support ARCH_MMAP_RND_BITS.
keescook at chromium.org
Tue Nov 3 15:18:47 PST 2015
On Tue, Nov 3, 2015 at 2:39 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Tue, Nov 03, 2015 at 11:19:44AM -0800, Kees Cook wrote:
>> On Tue, Nov 3, 2015 at 10:10 AM, Daniel Cashman <dcashman at android.com> wrote:
>> > From: dcashman <dcashman at google.com>
>> > arm: arch_mmap_rnd() uses a hard-code value of 8 to generate the
>> > random offset for the mmap base address. This value represents a
>> > compromise between increased ASLR effectiveness and avoiding
>> > address-space fragmentation. Replace it with a Kconfig option, which
>> > is sensibly bounded, so that platform developers may choose where to
>> > place this compromise. Keep 8 as the minimum acceptable value.
>> > Signed-off-by: Daniel Cashman <dcashman at google.com>
>> Acked-by: Kees Cook <keescook at chromium.org>
>> Russell, if you don't see any problems here, it might make sense not
>> to put this through the ARM patch tracker since it depends on the 1/2,
>> and I think x86 and arm64 (and possibly other arch) changes are coming
> Yes, it looks sane, though I do wonder whether there should also be
> a Kconfig option to allow archtectures to specify the default, instead
> of the default always being the minimum randomisation. I can see scope
> to safely pushing our mmap randomness default to 12, especially on 3GB
> setups, as we already have 11 bits of randomness on the sigpage and if
> enabled, 13 bits on the heap.
My thinking is that the there shouldn't be a reason to ever have a
minimum that was below the default. I have no objection with it, but
it seems needless. Frankly minimum is "0", really, so I don't think it
makes much sense to have default != arch minimum. I actually view
"arch minimum" as "known good", so if we are happy with raising the
"known good" value, that should be the new minimum.
Chrome OS Security
More information about the linux-arm-kernel