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

Groups > linux.kernel > #1622745 > unrolled thread

Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS

Started by"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
First post2017-04-13 08:40 +0200
Last post2017-04-13 09:00 +0200
Articles 6 — 4 participants

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

  Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-04-13 08:40 +0200
    Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> - 2017-04-13 09:00 +0200
      Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS Balbir Singh <bsingharora@gmail.com> - 2017-04-13 09:10 +0200
        Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS Bhupesh SHARMA <bhupesh.linux@gmail.com> - 2017-04-17 06:50 +0200
      Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS Bhupesh Sharma <bhsharma@redhat.com> - 2017-04-13 09:50 +0200
    Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS Bhupesh Sharma <bhsharma@redhat.com> - 2017-04-13 09:00 +0200

#1622745 — Re: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS

From"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Date2017-04-13 08:40 +0200
SubjectRe: [PATCH v3] powerpc: mm: support ARCH_MMAP_RND_BITS
Message-ID<tvGAa-7ok-9@gated-at.bofh.it>
Bhupesh Sharma <bhsharma@redhat.com> writes:

> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for
> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
> for the mmap base address for a ASLR ELF.
>
> This patch makes sure that powerpc mmap arch_mmap_rnd() implementation
> is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits
> and helpers to generate the mmap address randomization.
>
> The maximum and minimum randomization range values represent
> a compromise between increased ASLR effectiveness and avoiding
> address-space fragmentation.
>
> Using the Kconfig option and suitable /proc tunable, platform
> developers may choose where to place this compromise.
>
> Also this patch keeps the default values as new minimums.
>
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> ---
> * Changes since v2:
> v2 can be seen here (https://patchwork.kernel.org/patch/9551509/)
>     - Changed a few minimum and maximum randomization ranges as per Michael's suggestion.
>     - Corrected Kees's email address in the Reviewed-by line.
>     - Added further comments in kconfig to explain how the address ranges were worked out.
>
> * Changes since v1:
> v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
>     - No functional change in this patch.
>     - Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
>
>  arch/powerpc/Kconfig   | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  arch/powerpc/mm/mmap.c |  7 ++++---
>  2 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 97a8bc8..84aae67 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -22,6 +22,48 @@ config MMU
>  	bool
>  	default y
>  
> +# min bits determined by the following formula:
> +# VA_BITS - PAGE_SHIFT - CONSTANT
> +# where,
> +# 	VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT


Where did we derive that 46 bits from ? is that based on TASK_SIZE ?


> +# 	CONSTANT = 16 for 64BIT and 8 for 32BIT
> +config ARCH_MMAP_RND_BITS_MIN
> +       default 5 if PPC_256K_PAGES && 32BIT  # 31 - 18 - 8 = 5
> +       default 7 if PPC_64K_PAGES && 32BIT   # 31 - 16 - 8 = 7
> +       default 9 if PPC_16K_PAGES && 32BIT   # 31 - 14 - 8 = 9
> +       default 11 if PPC_4K_PAGES && 32BIT   # 31 - 12 - 8 = 11
> +       default 12 if PPC_256K_PAGES && 64BIT # 46 - 18 - 16 = 12
> +       default 14 if PPC_64K_PAGES && 64BIT  # 46 - 16 - 16 = 14
> +       default 16 if PPC_16K_PAGES && 64BIT  # 46 - 14 - 16 = 16
> +       default 18 if PPC_4K_PAGES && 64BIT   # 46 - 12 - 16 = 18
> +
> +# max bits determined by the following formula:


-aneesh

[toc] | [next] | [standalone]

#1622752

From"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Date2017-04-13 09:00 +0200
Message-ID<tvGTv-7xN-5@gated-at.bofh.it>
In reply to#1622745

On Thursday 13 April 2017 12:22 PM, Bhupesh Sharma wrote:
> Hi Aneesh,
>
> On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
> <aneesh.kumar@linux.vnet.ibm.com> wrote:
>> Bhupesh Sharma <bhsharma@redhat.com> writes:
>>
>>> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for
>>> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
>>> for the mmap base address for a ASLR ELF.
>>>
>>> This patch makes sure that powerpc mmap arch_mmap_rnd() implementation
>>> is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits
>>> and helpers to generate the mmap address randomization.
>>>
>>> The maximum and minimum randomization range values represent
>>> a compromise between increased ASLR effectiveness and avoiding
>>> address-space fragmentation.
>>>
>>> Using the Kconfig option and suitable /proc tunable, platform
>>> developers may choose where to place this compromise.
>>>
>>> Also this patch keeps the default values as new minimums.
>>>
>>> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
>>> Reviewed-by: Kees Cook <keescook@chromium.org>
>>> ---
>>> * Changes since v2:
>>> v2 can be seen here (https://patchwork.kernel.org/patch/9551509/)
>>>     - Changed a few minimum and maximum randomization ranges as per Michael's suggestion.
>>>     - Corrected Kees's email address in the Reviewed-by line.
>>>     - Added further comments in kconfig to explain how the address ranges were worked out.
>>>
>>> * Changes since v1:
>>> v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
>>>     - No functional change in this patch.
>>>     - Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
>>>
>>>  arch/powerpc/Kconfig   | 44 ++++++++++++++++++++++++++++++++++++++++++++
>>>  arch/powerpc/mm/mmap.c |  7 ++++---
>>>  2 files changed, 48 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index 97a8bc8..84aae67 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -22,6 +22,48 @@ config MMU
>>>       bool
>>>       default y
>>>
>>> +# min bits determined by the following formula:
>>> +# VA_BITS - PAGE_SHIFT - CONSTANT
>>> +# where,
>>> +#    VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT
>>
>>
>> Where did we derive that 46 bits from ? is that based on TASK_SIZE ?
>
> Yes. It was derived from TASK_SIZE :
> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105
>

That is getting update to 128TB by default and conditionally to 512TB

-aneesh

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

#1622757

FromBalbir Singh <bsingharora@gmail.com>
Date2017-04-13 09:10 +0200
Message-ID<tvH3b-7S2-1@gated-at.bofh.it>
In reply to#1622752
>>
>> Yes. It was derived from TASK_SIZE :
>>
>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105
>>
>
> That is getting update to 128TB by default and conditionally to 512TB
>

Since this is compile time, we should probably keep the scope to 128TB
for now and see if we want to change things at run time later, since
the expansion is based on a hint. Suggestions?

Balbir

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

#1624530

FromBhupesh SHARMA <bhupesh.linux@gmail.com>
Date2017-04-17 06:50 +0200
Message-ID<tx6LT-4FQ-1@gated-at.bofh.it>
In reply to#1622757
On Thu, Apr 13, 2017 at 12:39 PM, Balbir Singh <bsingharora@gmail.com> wrote:
>>>
>>> Yes. It was derived from TASK_SIZE :
>>>
>>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105
>>>
>>
>> That is getting update to 128TB by default and conditionally to 512TB
>>
>
> Since this is compile time, we should probably keep the scope to 128TB
> for now and see if we want to change things at run time later, since
> the expansion is based on a hint. Suggestions?
>

I think this makes sense. If the conditional expansion to 512TB is
protected by a kconfig symbol, we can use the same to have separate
ranges for 128TB and 512TB using the kconfig symbol as the
differentiating factor.

Also please let me know which branch/tree to use where we are done
with the change making the default to 128TB. My v2 was based on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
(mater branch), where the TASK_SIZE is set to 46-bits inside
'arch/powerpc/include/asm/processor.h'.

So that I can spin the v3 accordingly.

Thanks,
Bhupesh

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

#1622797

FromBhupesh Sharma <bhsharma@redhat.com>
Date2017-04-13 09:50 +0200
Message-ID<tvHFU-8bX-9@gated-at.bofh.it>
In reply to#1622752
On Thu, Apr 13, 2017 at 12:28 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
>
>
> On Thursday 13 April 2017 12:22 PM, Bhupesh Sharma wrote:
>>
>> Hi Aneesh,
>>
>> On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
>> <aneesh.kumar@linux.vnet.ibm.com> wrote:
>>>
>>> Bhupesh Sharma <bhsharma@redhat.com> writes:
>>>
>>>> powerpc arch_mmap_rnd() currently uses hard-coded values -
>>>> (23-PAGE_SHIFT) for
>>>> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
>>>> for the mmap base address for a ASLR ELF.
>>>>
>>>> This patch makes sure that powerpc mmap arch_mmap_rnd() implementation
>>>> is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits
>>>> and helpers to generate the mmap address randomization.
>>>>
>>>> The maximum and minimum randomization range values represent
>>>> a compromise between increased ASLR effectiveness and avoiding
>>>> address-space fragmentation.
>>>>
>>>> Using the Kconfig option and suitable /proc tunable, platform
>>>> developers may choose where to place this compromise.
>>>>
>>>> Also this patch keeps the default values as new minimums.
>>>>
>>>> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
>>>> Reviewed-by: Kees Cook <keescook@chromium.org>
>>>> ---
>>>> * Changes since v2:
>>>> v2 can be seen here (https://patchwork.kernel.org/patch/9551509/)
>>>>     - Changed a few minimum and maximum randomization ranges as per
>>>> Michael's suggestion.
>>>>     - Corrected Kees's email address in the Reviewed-by line.
>>>>     - Added further comments in kconfig to explain how the address
>>>> ranges were worked out.
>>>>
>>>> * Changes since v1:
>>>> v1 can be seen here
>>>> (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
>>>>     - No functional change in this patch.
>>>>     - Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
>>>>
>>>>  arch/powerpc/Kconfig   | 44
>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>  arch/powerpc/mm/mmap.c |  7 ++++---
>>>>  2 files changed, 48 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> index 97a8bc8..84aae67 100644
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -22,6 +22,48 @@ config MMU
>>>>       bool
>>>>       default y
>>>>
>>>> +# min bits determined by the following formula:
>>>> +# VA_BITS - PAGE_SHIFT - CONSTANT
>>>> +# where,
>>>> +#    VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT
>>>
>>>
>>>
>>> Where did we derive that 46 bits from ? is that based on TASK_SIZE ?
>>
>>
>> Yes. It was derived from TASK_SIZE :
>>
>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105
>>
>
> That is getting update to 128TB by default and conditionally to 512TB

Can't find the relevant patch in linus's master branch.
Please share the appropriate patch/discussion link.

Regards,
Bhupesh

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

#1622755

FromBhupesh Sharma <bhsharma@redhat.com>
Date2017-04-13 09:00 +0200
Message-ID<tvGTv-7xN-7@gated-at.bofh.it>
In reply to#1622745
Hi Aneesh,

On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Bhupesh Sharma <bhsharma@redhat.com> writes:
>
>> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for
>> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
>> for the mmap base address for a ASLR ELF.
>>
>> This patch makes sure that powerpc mmap arch_mmap_rnd() implementation
>> is similar to other ARCHs (like x86, arm64) and uses mmap_rnd_bits
>> and helpers to generate the mmap address randomization.
>>
>> The maximum and minimum randomization range values represent
>> a compromise between increased ASLR effectiveness and avoiding
>> address-space fragmentation.
>>
>> Using the Kconfig option and suitable /proc tunable, platform
>> developers may choose where to place this compromise.
>>
>> Also this patch keeps the default values as new minimums.
>>
>> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
>> Reviewed-by: Kees Cook <keescook@chromium.org>
>> ---
>> * Changes since v2:
>> v2 can be seen here (https://patchwork.kernel.org/patch/9551509/)
>>     - Changed a few minimum and maximum randomization ranges as per Michael's suggestion.
>>     - Corrected Kees's email address in the Reviewed-by line.
>>     - Added further comments in kconfig to explain how the address ranges were worked out.
>>
>> * Changes since v1:
>> v1 can be seen here (https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153594.html)
>>     - No functional change in this patch.
>>     - Dropped PATCH 2/2 from v1 as recommended by Kees Cook.
>>
>>  arch/powerpc/Kconfig   | 44 ++++++++++++++++++++++++++++++++++++++++++++
>>  arch/powerpc/mm/mmap.c |  7 ++++---
>>  2 files changed, 48 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 97a8bc8..84aae67 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -22,6 +22,48 @@ config MMU
>>       bool
>>       default y
>>
>> +# min bits determined by the following formula:
>> +# VA_BITS - PAGE_SHIFT - CONSTANT
>> +# where,
>> +#    VA_BITS = 46 bits for 64BIT and 4GB - 1 Page = 31 bits for 32BIT
>
>
> Where did we derive that 46 bits from ? is that based on TASK_SIZE ?

Yes. It was derived from TASK_SIZE :
http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105

Regards,
Bhupesh

>
>> +#    CONSTANT = 16 for 64BIT and 8 for 32BIT
>> +config ARCH_MMAP_RND_BITS_MIN
>> +       default 5 if PPC_256K_PAGES && 32BIT  # 31 - 18 - 8 = 5
>> +       default 7 if PPC_64K_PAGES && 32BIT   # 31 - 16 - 8 = 7
>> +       default 9 if PPC_16K_PAGES && 32BIT   # 31 - 14 - 8 = 9
>> +       default 11 if PPC_4K_PAGES && 32BIT   # 31 - 12 - 8 = 11
>> +       default 12 if PPC_256K_PAGES && 64BIT # 46 - 18 - 16 = 12
>> +       default 14 if PPC_64K_PAGES && 64BIT  # 46 - 16 - 16 = 14
>> +       default 16 if PPC_16K_PAGES && 64BIT  # 46 - 14 - 16 = 16
>> +       default 18 if PPC_4K_PAGES && 64BIT   # 46 - 12 - 16 = 18
>> +
>> +# max bits determined by the following formula:
>
>
> -aneesh
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web