From: Matt Redfearn <matt.redfearn@imgtec.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
Linux MIPS Mailing List <linux-mips@linux-mips.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
LKML <linux-kernel@vger.kernel.org>,
Daniel Cashman <dcashman@android.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] MIPS: Add support for ARCH_MMAP_RND_{COMPAT_}BITS
Date: Mon, 28 Nov 2016 16:10:39 +0000 [thread overview]
Message-ID: <a8dd7013-979a-6352-cc75-68383a111ff0@imgtec.com> (raw)
In-Reply-To: <CAGXu5jLT-V3+3_KSAfxbN3yY22xRh3tvs1wpL+mwk1En8MC6Bg@mail.gmail.com>
Hi Kees
On 25/11/16 20:00, Kees Cook wrote:
> On Thu, Nov 24, 2016 at 9:32 AM, Matt Redfearn <matt.redfearn@imgtec.com> wrote:
>> arch_mmap_rnd() uses hard-coded limits of 16MB for the randomisation
>> of mmap within 32bit processes and 256MB in 64bit processes. Since v4.4
>> other arches support tuning this value in /proc/sys/vm/mmap_rnd_bits.
>> Add support for this to MIPS.
>>
>> Set the minimum(default) number of bits randomisation for 32bit to 8 -
>> which with 4k pagesize is unchanged from the current 16MB total
>> randomness. The minimum(default) for 64bit is 12bits, again with 4k
>> pagesize this is the same as the current 256MB.
>>
>> This patch is necessary for MIPS32 to pass the Android CTS tests, with
>> the number of random bits set to 15.
>>
>> Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
>> ---
>>
>> arch/mips/Kconfig | 16 ++++++++++++++++
>> arch/mips/mm/mmap.c | 10 +++++-----
>> 2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>> index b3c5bde43d34..d72cf6129b2c 100644
>> --- a/arch/mips/Kconfig
>> +++ b/arch/mips/Kconfig
>> @@ -13,6 +13,8 @@ config MIPS
>> select HAVE_PERF_EVENTS
>> select PERF_USE_VMALLOC
>> select HAVE_ARCH_KGDB
>> + select HAVE_ARCH_MMAP_RND_BITS if MMU
>> + select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
>> select HAVE_ARCH_SECCOMP_FILTER
>> select HAVE_ARCH_TRACEHOOK
>> select HAVE_CBPF_JIT if !CPU_MICROMIPS
>> @@ -3073,6 +3075,20 @@ config MMU
>> bool
>> default y
>>
>> +config ARCH_MMAP_RND_BITS_MIN
>> + default 12 if 64BIT
>> + default 8
>> +
>> +config ARCH_MMAP_RND_BITS_MAX
>> + default 18 if 64BIT
>> + default 15
>> +
>> +config ARCH_MMAP_RND_COMPAT_BITS_MIN
>> + default 8
>> +
>> +config ARCH_MMAP_RND_COMPAT_BITS_MAX
>> + default 15
>> +
>> config I8253
>> bool
>> select CLKSRC_I8253
>> diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
>> index d08ea3ff0f53..d6d92c02308d 100644
>> --- a/arch/mips/mm/mmap.c
>> +++ b/arch/mips/mm/mmap.c
>> @@ -146,14 +146,14 @@ unsigned long arch_mmap_rnd(void)
>> {
>> unsigned long rnd;
>>
>> - rnd = get_random_long();
>> - rnd <<= PAGE_SHIFT;
>> +#ifdef CONFIG_COMPAT
>> if (TASK_IS_32BIT_ADDR)
>> - rnd &= 0xfffffful;
>> + rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
>> else
>> - rnd &= 0xffffffful;
>> +#endif /* CONFIG_COMPAT */
>> + rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
>>
>> - return rnd;
>> + return rnd << PAGE_SHIFT;
>> }
>>
>> void arch_pick_mmap_layout(struct mm_struct *mm)
>> --
>> 2.7.4
>>
> Excellent!
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
>
> Out of curiosity, how were the maxs of 15 and 18 chosen?
The maximum of 15 bits for 32 bit processes was the minimum required to
pass the Android CTS tests with Nougat using 4k pages, but with 64k
pages would be on the limit of the virtual address space. For 64 bit
processes, I just allowed an 3 extra bits of randomness within the
larger virtual address space, similar to the ARM64 limit.
Thanks,
Matt
>
> -Kees
>
next prev parent reply other threads:[~2016-11-28 16:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 17:32 Matt Redfearn
2016-11-25 20:00 ` Kees Cook
2016-11-28 16:10 ` Matt Redfearn [this message]
2016-11-28 18:17 ` Kees Cook
2016-11-29 0:47 ` Dan 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=a8dd7013-979a-6352-cc75-68383a111ff0@imgtec.com \
--to=matt.redfearn@imgtec.com \
--cc=akpm@linux-foundation.org \
--cc=dcashman@android.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.gortmaker@windriver.com \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®