Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1272670 > unrolled thread

[PATCH v3 2/4] arm: mm: support ARCH_MMAP_RND_BITS.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v3 2/4] arm: mm: support ARCH_MMAP_RND_BITS. Daniel Cashman <dcashman@android.com> - 2015-11-19 00:30 +0100
    [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Daniel Cashman <dcashman@android.com> - 2015-11-19 00:30 +0100
      Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Will Deacon <will.deacon@arm.com> - 2015-11-23 16:10 +0100
        Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Daniel Cashman <dcashman@android.com> - 2015-11-23 20:00 +0100
          Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Michael Ellerman <mpe@ellerman.id.au> - 2015-11-25 05:30 +0100
            Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Daniel Cashman <dcashman@android.com> - 2015-11-25 20:40 +0100
          Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Catalin Marinas <catalin.marinas@arm.com> - 2015-11-25 13:10 +0100
            Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Daniel Cashman <dcashman@android.com> - 2015-11-25 21:40 +0100
              Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2015-11-27 09:40 +0100
                Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS. Catalin Marinas <catalin.marinas@arm.com> - 2015-11-27 10:40 +0100

#1272670 — [PATCH v3 2/4] arm: mm: support ARCH_MMAP_RND_BITS.

From: dcashman <dcashman@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@google.com>
---
 arch/arm/Kconfig   | 10 ++++++++++
 arch/arm/mm/mmap.c |  3 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0365cbb..ca2e43a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -35,6 +35,7 @@ config ARM
 	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
 	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32
 	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32
+	select HAVE_ARCH_MMAP_RND_BITS
 	select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_BPF_JIT
@@ -306,6 +307,15 @@ config MMU
 	  Select if you want MMU-based virtualised addressing space
 	  support by paged memory management. If unsure, say 'Y'.
 
+config ARCH_MMAP_RND_BITS_MIN
+	default 8
+
+config ARCH_MMAP_RND_BITS_MAX
+	default 14 if MMU && PAGE_OFFSET=0x40000000
+	default 15 if MMU && PAGE_OFFSET=0x80000000
+	default 16 if MMU
+	default 8
+
 #
 # The "ARM system type" choice list is ordered alphabetically by option
 # text.  Please add new entries in the option alphabetic order.
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index 407dc78..c938693 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -173,8 +173,7 @@ unsigned long arch_mmap_rnd(void)
 {
 	unsigned long rnd;
 
-	/* 8 bits of randomness in 20 address space bits */
-	rnd = (unsigned long)get_random_int() % (1 << 8);
+	rnd = (unsigned long)get_random_int() % (1 << mmap_rnd_bits);
 
 	return rnd << PAGE_SHIFT;
 }
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1272676 — [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

From: dcashman <dcashman@google.com>

arm64: arch_mmap_rnd() uses STACK_RND_MASK 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 default values as new minimums.

Signed-off-by: Daniel Cashman <dcashman@google.com>
---
 arch/arm64/Kconfig   | 23 +++++++++++++++++++++++
 arch/arm64/mm/mmap.c |  6 ++++--
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9ac16a4..be38e4c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -51,6 +51,8 @@ config ARM64
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
 	select HAVE_ARCH_KGDB
+	select HAVE_ARCH_MMAP_RND_BITS
+	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_BPF_JIT
@@ -104,6 +106,27 @@ config ARCH_PHYS_ADDR_T_64BIT
 config MMU
 	def_bool y
 
+config ARCH_MMAP_RND_BITS_MIN
+       default 15 if ARM64_64K_PAGES
+       default 19
+
+config ARCH_MMAP_RND_BITS_MAX
+       default 20 if ARM64_64K_PAGES && ARCH_VA_BITS=39
+       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
+
+config ARCH_MMAP_RND_COMPAT_BITS_MAX
+       default 16
+
 config NO_IOPORT_MAP
 	def_bool y if !PCI
 
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index ed17747..b84d5b1 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -51,8 +51,10 @@ unsigned long arch_mmap_rnd(void)
 {
 	unsigned long rnd;
 
-	rnd = (unsigned long)get_random_int() & STACK_RND_MASK;
-
+	if (test_thread_flag(TIF_32BIT))
+		rnd = (unsigned long)get_random_int() % (1 << mmap_rnd_compat_bits);
+	else
+		rnd = (unsigned long)get_random_int() % (1 << mmap_rnd_bits);
 	return rnd << PAGE_SHIFT;
 }
 
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275466 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

On Wed, Nov 18, 2015 at 03:20:07PM -0800, Daniel Cashman wrote:
> From: dcashman <dcashman@google.com>
> 
> arm64: arch_mmap_rnd() uses STACK_RND_MASK 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 default values as new minimums.
> 
> Signed-off-by: Daniel Cashman <dcashman@google.com>
> ---
>  arch/arm64/Kconfig   | 23 +++++++++++++++++++++++
>  arch/arm64/mm/mmap.c |  6 ++++--
>  2 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9ac16a4..be38e4c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -51,6 +51,8 @@ config ARM64
>  	select HAVE_ARCH_JUMP_LABEL
>  	select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
>  	select HAVE_ARCH_KGDB
> +	select HAVE_ARCH_MMAP_RND_BITS
> +	select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>  	select HAVE_ARCH_SECCOMP_FILTER
>  	select HAVE_ARCH_TRACEHOOK
>  	select HAVE_BPF_JIT
> @@ -104,6 +106,27 @@ config ARCH_PHYS_ADDR_T_64BIT
>  config MMU
>  	def_bool y
>  
> +config ARCH_MMAP_RND_BITS_MIN
> +       default 15 if ARM64_64K_PAGES
> +       default 19
> +
> +config ARCH_MMAP_RND_BITS_MAX
> +       default 20 if ARM64_64K_PAGES && ARCH_VA_BITS=39
> +       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.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275749 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

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
>> +       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.

We could move this logic into the code where min/max are initialized,
but that would create its own mess, creating new Kconfig values to
introduce it in an arch-agnostic way after patch-set v2 moved that to
mm/mmap.c instread of arch/${arch}/mm/mmap.c Suggestions welcome.

Thank You,
Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277008 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

On Mon, 2015-11-23 at 10:55 -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
> > > +       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.
> 
> We could move this logic into the code where min/max are initialized,
> but that would create its own mess, creating new Kconfig values to
> introduce it in an arch-agnostic way after patch-set v2 moved that to
> mm/mmap.c instead of arch/${arch}/mm/mmap.c Suggestions welcome.


Could we instead change the meaning of the mmap_rnd_bits value to be the number
of address space bits that may be randomised?

ie. 40 would mean "please randomise in a 1T range", which with PAGE_SIZE=4K
gives you 28 random bits. etc.

That would make the value independent of PAGE_SIZE, and only depend on the size
of the address space.

It would also mean the values userspace sets and sees don't need to change if the
kernel PAGE_SIZE changes. (which probably doesn't happen often but still)

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277739 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

On 11/24/2015 08:26 PM, Michael Ellerman wrote:
> On Mon, 2015-11-23 at 10:55 -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
>>>> +       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.
>>
>> We could move this logic into the code where min/max are initialized,
>> but that would create its own mess, creating new Kconfig values to
>> introduce it in an arch-agnostic way after patch-set v2 moved that to
>> mm/mmap.c instead of arch/${arch}/mm/mmap.c Suggestions welcome.
> 
> 
> Could we instead change the meaning of the mmap_rnd_bits value to be the number
> of address space bits that may be randomised?
> 
> ie. 40 would mean "please randomise in a 1T range", which with PAGE_SIZE=4K
> gives you 28 random bits. etc.
> 
> That would make the value independent of PAGE_SIZE, and only depend on the size
> of the address space.
> 
> It would also mean the values userspace sets and sees don't need to change if the
> kernel PAGE_SIZE changes. (which probably doesn't happen often but still)

This is an intriguing idea. It might actually be more meaningful to a
sysadmin when weighing how high they're willing to go, since it makes
the relation to the address space overall more apparent.  Though the
cost would be more obvious, the benefit would become less-so, as the
amount of entropy used, and thus expected brute-force requirements would
be hidden.  I'll defer to Andrew Morton, as the maintainer, to make this
decision as I think both approaches are valid.

Thank You,
Dan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277292 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

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.

> >> +       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?

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1277787 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278620 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

2015-11-25 23:39 GMT+03:00 Daniel Cashman <dcashman@android.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
>

For kasan, we calculate KASAN_SHADOW_OFFSET in Makefile, because we need to use
that value in Makefiles.

For ARCH_MMAP_RND_COMPAT_BITS_MIN/MAX I don't see a reason why it has
to be in Kconfig.
Can't we just use your formula to #define ARCH_MMAP_RND_COMPAT_BITS_*
in some arch header?

> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1278675 — Re: [PATCH v3 3/4] arm64: mm: support ARCH_MMAP_RND_BITS.

On Fri, Nov 27, 2015 at 11:36:30AM +0300, Andrey Ryabinin wrote:
> 2015-11-25 23:39 GMT+03:00 Daniel Cashman <dcashman@android.com>:
> > On 11/25/2015 04:06 AM, Catalin Marinas wrote:
> >> 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
> 
> For kasan, we calculate KASAN_SHADOW_OFFSET in Makefile, because we need to use
> that value in Makefiles.
> 
> For ARCH_MMAP_RND_COMPAT_BITS_MIN/MAX I don't see a reason why it has
> to be in Kconfig.
> Can't we just use your formula to #define ARCH_MMAP_RND_COMPAT_BITS_*
> in some arch header?

Because there is another option, ARCH_MMAP_RND_BITS depending on EXPERT
which uses the MIN/MAX range defined per architecture. Since it's an
expert feature, we could as well ignore the MIN/MAX in Kconfig and just
add BUILD_BUG_ON checks to the code. This way we could simply define
them in C files.

Alternatively, add arithmetics support to kbuild ;).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web