From: dcashman@android.com (Daniel Cashman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.
Date: Wed, 25 Nov 2015 12:39:13 -0800 [thread overview]
Message-ID: <56561C71.30602@android.com> (raw)
In-Reply-To: <20151125120601.GC3109@e104818-lin.cambridge.arm.com>
On 11/25/2015 04:06 AM, Catalin Marinas wrote:
> On Mon, Nov 23, 2015 at 10:55:16AM -0800, Daniel Cashman wrote:
>> On 11/23/2015 07:04 AM, Will Deacon wrote:
>>> On Wed, Nov 18, 2015 at 03:20:07PM -0800, Daniel Cashman wrote:
>>>> +config ARCH_MMAP_RND_BITS_MAX
>>>> + default 20 if ARM64_64K_PAGES && ARCH_VA_BITS=39
>
> Where is ARCH_VA_BITS defined? We only have options like
> ARM64_VA_BITS_39.
>
> BTW, we no longer allow the 64K pages and 39-bit VA combination.
It is not, and should have been ARM64_VA_BITS. This stanza was meant to
mimic the one for ARM64_VA_BITS. Thank you for pointing this, and the
39-bit combination out.
>>>> + default 24 if ARCH_VA_BITS=39
>>>> + default 23 if ARM64_64K_PAGES && ARCH_VA_BITS=42
>>>> + default 27 if ARCH_VA_BITS=42
>>>> + default 29 if ARM64_64K_PAGES && ARCH_VA_BITS=48
>>>> + default 33 if ARCH_VA_BITS=48
>>>> + default 15 if ARM64_64K_PAGES
>>>> + default 19
>>>> +
>>>> +config ARCH_MMAP_RND_COMPAT_BITS_MIN
>>>> + default 7 if ARM64_64K_PAGES
>>>> + default 11
>>>
>>> FYI: we now support 16k pages too, so this might need updating. It would
>>> be much nicer if this was somehow computed rather than have the results
>>> all open-coded like this.
>>
>> Yes, I ideally wanted this to be calculated based on the different page
>> options and VA_BITS (which itself has a similar stanza), but I don't
>> know how to do that/if it is currently supported in Kconfig. This would
>> be even more desirable with the addition of 16K_PAGES, as with this
>> setup we have a combinatorial problem.
>
> For KASan, we ended up calculating KASAN_SHADOW_OFFSET in
> arch/arm64/Makefile. What would the formula be for the above
> ARCH_MMAP_RND_BITS_MAX?
The general formula I used ended up being:
_max = floor(log(TASK_SIZE)) - log(PAGE_SIZE) - 3
which in the case of arm64 ended up being VA_BITS - PAGE_SHIFT - 3.
Aside: following this would actually put COMPAT_BITS_MAX at 17 for 4k
pages, rather than 16, but I left it at 16 to mirror what was put in
arch/arm/Kconfig.
Thank You,
Dan
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Cashman <dcashman@android.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>,
dcashman@google.com, linux-doc@vger.kernel.org,
linux-mm@kvack.org, hpa@zytor.com, mingo@kernel.org,
aarcange@redhat.com, linux@arm.linux.org.uk, corbet@lwn.net,
xypron.glpk@gmx.de, x86@kernel.org, hecmargi@upv.es,
mgorman@suse.de, rientjes@google.com, bp@suse.de, nnk@google.com,
dzickus@redhat.com, keescook@chromium.org, jpoimboe@redhat.com,
tglx@linutronix.de, n-horiguchi@ah.jp.nec.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, salyzyn@android.com,
ebiederm@xmission.com, jeffv@google.com,
akpm@linux-foundation.org, kirill.shutemov@linux.intel.com
Subject: Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.
Date: Wed, 25 Nov 2015 12:39:13 -0800 [thread overview]
Message-ID: <56561C71.30602@android.com> (raw)
In-Reply-To: <20151125120601.GC3109@e104818-lin.cambridge.arm.com>
On 11/25/2015 04:06 AM, Catalin Marinas wrote:
> On Mon, Nov 23, 2015 at 10:55:16AM -0800, Daniel Cashman wrote:
>> On 11/23/2015 07:04 AM, Will Deacon wrote:
>>> On Wed, Nov 18, 2015 at 03:20:07PM -0800, Daniel Cashman wrote:
>>>> +config ARCH_MMAP_RND_BITS_MAX
>>>> + default 20 if ARM64_64K_PAGES && ARCH_VA_BITS=39
>
> Where is ARCH_VA_BITS defined? We only have options like
> ARM64_VA_BITS_39.
>
> BTW, we no longer allow the 64K pages and 39-bit VA combination.
It is not, and should have been ARM64_VA_BITS. This stanza was meant to
mimic the one for ARM64_VA_BITS. Thank you for pointing this, and the
39-bit combination out.
>>>> + default 24 if ARCH_VA_BITS=39
>>>> + default 23 if ARM64_64K_PAGES && ARCH_VA_BITS=42
>>>> + default 27 if ARCH_VA_BITS=42
>>>> + default 29 if ARM64_64K_PAGES && ARCH_VA_BITS=48
>>>> + default 33 if ARCH_VA_BITS=48
>>>> + default 15 if ARM64_64K_PAGES
>>>> + default 19
>>>> +
>>>> +config ARCH_MMAP_RND_COMPAT_BITS_MIN
>>>> + default 7 if ARM64_64K_PAGES
>>>> + default 11
>>>
>>> FYI: we now support 16k pages too, so this might need updating. It would
>>> be much nicer if this was somehow computed rather than have the results
>>> all open-coded like this.
>>
>> Yes, I ideally wanted this to be calculated based on the different page
>> options and VA_BITS (which itself has a similar stanza), but I don't
>> know how to do that/if it is currently supported in Kconfig. This would
>> be even more desirable with the addition of 16K_PAGES, as with this
>> setup we have a combinatorial problem.
>
> For KASan, we ended up calculating KASAN_SHADOW_OFFSET in
> arch/arm64/Makefile. What would the formula be for the above
> ARCH_MMAP_RND_BITS_MAX?
The general formula I used ended up being:
_max = floor(log(TASK_SIZE)) - log(PAGE_SIZE) - 3
which in the case of arm64 ended up being VA_BITS - PAGE_SHIFT - 3.
Aside: following this would actually put COMPAT_BITS_MAX at 17 for 4k
pages, rather than 16, but I left it at 16 to mirror what was put in
arch/arm/Kconfig.
Thank You,
Dan
--
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: Daniel Cashman <dcashman@android.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>,
dcashman@google.com, linux-doc@vger.kernel.org,
linux-mm@kvack.org, hpa@zytor.com, mingo@kernel.org,
aarcange@redhat.com, linux@arm.linux.org.uk, corbet@lwn.net,
xypron.glpk@gmx.de, x86@kernel.org, hecmargi@upv.es,
mgorman@suse.de, rientjes@google.com, bp@suse.de, nnk@google.com,
dzickus@redhat.com, keescook@chromium.org, jpoimboe@redhat.com,
tglx@linutronix.de, n-horiguchi@ah.jp.nec.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, salyzyn@android.com,
ebiederm@xmission.com, jeffv@google.com,
akpm@linux-foundation.org, kirill.shutemov@linux.intel.com
Subject: Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.
Date: Wed, 25 Nov 2015 12:39:13 -0800 [thread overview]
Message-ID: <56561C71.30602@android.com> (raw)
In-Reply-To: <20151125120601.GC3109@e104818-lin.cambridge.arm.com>
On 11/25/2015 04:06 AM, Catalin Marinas wrote:
> On Mon, Nov 23, 2015 at 10:55:16AM -0800, Daniel Cashman wrote:
>> On 11/23/2015 07:04 AM, Will Deacon wrote:
>>> On Wed, Nov 18, 2015 at 03:20:07PM -0800, Daniel Cashman wrote:
>>>> +config ARCH_MMAP_RND_BITS_MAX
>>>> + default 20 if ARM64_64K_PAGES && ARCH_VA_BITS=39
>
> Where is ARCH_VA_BITS defined? We only have options like
> ARM64_VA_BITS_39.
>
> BTW, we no longer allow the 64K pages and 39-bit VA combination.
It is not, and should have been ARM64_VA_BITS. This stanza was meant to
mimic the one for ARM64_VA_BITS. Thank you for pointing this, and the
39-bit combination out.
>>>> + default 24 if ARCH_VA_BITS=39
>>>> + default 23 if ARM64_64K_PAGES && ARCH_VA_BITS=42
>>>> + default 27 if ARCH_VA_BITS=42
>>>> + default 29 if ARM64_64K_PAGES && ARCH_VA_BITS=48
>>>> + default 33 if ARCH_VA_BITS=48
>>>> + default 15 if ARM64_64K_PAGES
>>>> + default 19
>>>> +
>>>> +config ARCH_MMAP_RND_COMPAT_BITS_MIN
>>>> + default 7 if ARM64_64K_PAGES
>>>> + default 11
>>>
>>> FYI: we now support 16k pages too, so this might need updating. It would
>>> be much nicer if this was somehow computed rather than have the results
>>> all open-coded like this.
>>
>> Yes, I ideally wanted this to be calculated based on the different page
>> options and VA_BITS (which itself has a similar stanza), but I don't
>> know how to do that/if it is currently supported in Kconfig. This would
>> be even more desirable with the addition of 16K_PAGES, as with this
>> setup we have a combinatorial problem.
>
> For KASan, we ended up calculating KASAN_SHADOW_OFFSET in
> arch/arm64/Makefile. What would the formula be for the above
> ARCH_MMAP_RND_BITS_MAX?
The general formula I used ended up being:
_max = floor(log(TASK_SIZE)) - log(PAGE_SIZE) - 3
which in the case of arm64 ended up being VA_BITS - PAGE_SHIFT - 3.
Aside: following this would actually put COMPAT_BITS_MAX at 17 for 4k
pages, rather than 16, but I left it at 16 to mirror what was put in
arch/arm/Kconfig.
Thank You,
Dan
next prev parent reply other threads:[~2015-11-25 20:39 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 23:20 [PATCH v3 0/4] Allow customizable random offset to mmap_base address Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` [PATCH v3 1/4] mm: mmap: Add new /proc tunable for mmap_base ASLR Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` [PATCH v3 2/4] arm: mm: support ARCH_MMAP_RND_BITS Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` [PATCH v3 3/4] arm64: " Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` [PATCH v3 4/4] x86: " Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-18 23:20 ` Daniel Cashman
2015-11-19 0:16 ` Daniel Cashman
2015-11-19 0:16 ` Daniel Cashman
2015-11-19 0:16 ` Daniel Cashman
2015-11-23 15:04 ` [PATCH v3 3/4] arm64: " Will Deacon
2015-11-23 15:04 ` Will Deacon
2015-11-23 15:04 ` Will Deacon
2015-11-23 18:55 ` Daniel Cashman
2015-11-23 18:55 ` Daniel Cashman
2015-11-23 18:55 ` Daniel Cashman
2015-11-25 4:26 ` Michael Ellerman
2015-11-25 4:26 ` Michael Ellerman
2015-11-25 4:26 ` Michael Ellerman
2015-11-25 19:32 ` Daniel Cashman
2015-11-25 19:32 ` Daniel Cashman
2015-11-25 19:32 ` Daniel Cashman
2015-11-25 12:06 ` Catalin Marinas
2015-11-25 12:06 ` Catalin Marinas
2015-11-25 12:06 ` Catalin Marinas
2015-11-25 20:39 ` Daniel Cashman [this message]
2015-11-25 20:39 ` Daniel Cashman
2015-11-25 20:39 ` Daniel Cashman
2015-11-27 8:36 ` Andrey Ryabinin
2015-11-27 8:36 ` Andrey Ryabinin
2015-11-27 8:36 ` Andrey Ryabinin
2015-11-27 9:32 ` Catalin Marinas
2015-11-27 9:32 ` Catalin Marinas
2015-11-27 9:32 ` Catalin Marinas
2015-11-19 0:14 ` [PATCH v3 1/4] mm: mmap: Add new /proc tunable for mmap_base ASLR Daniel Cashman
2015-11-19 0:14 ` Daniel Cashman
2015-11-19 0:14 ` Daniel Cashman
2015-11-25 0:40 ` Andrew Morton
2015-11-25 0:40 ` Andrew Morton
2015-11-25 0:40 ` Andrew Morton
2015-11-25 0:47 ` Kees Cook
2015-11-25 0:47 ` Kees Cook
2015-11-25 0:47 ` Kees Cook
2015-11-25 19:16 ` Daniel Cashman
2015-11-25 19:16 ` Daniel Cashman
2015-11-25 19:16 ` Daniel Cashman
2015-11-25 4:40 ` Michael Ellerman
2015-11-25 4:40 ` Michael Ellerman
2015-11-25 4:40 ` Michael Ellerman
2015-11-25 19:36 ` Daniel Cashman
2015-11-25 19:36 ` Daniel Cashman
2015-11-25 19:36 ` Daniel Cashman
2015-11-25 0:39 ` [PATCH v3 0/4] Allow customizable random offset to mmap_base address Andrew Morton
2015-11-25 0:39 ` Andrew Morton
2015-11-25 0:39 ` Andrew Morton
2015-11-25 19:07 ` Daniel Cashman
2015-11-25 19:07 ` Daniel Cashman
2015-11-25 19:07 ` Daniel Cashman
2015-11-26 15:11 ` Martin Schwidefsky
2015-11-26 15:11 ` Martin Schwidefsky
2015-11-26 15:11 ` Martin Schwidefsky
2015-11-26 7:07 ` Michael Ellerman
2015-11-26 7:07 ` Michael Ellerman
2015-11-26 7:07 ` Michael Ellerman
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=56561C71.30602@android.com \
--to=dcashman@android.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.