All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Nicholas Piggin <npiggin@gmail.com>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 09/10] powerpc/mm: Convert to default topdown mmap layout
Date: Fri, 10 Dec 2021 10:56:11 +1100	[thread overview]
Message-ID: <87r1almixw.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <7990b457-0b16-b4fb-d279-89a4cdc093a7@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 09/12/2021 à 12:22, Michael Ellerman a écrit :
>> Nicholas Piggin <npiggin@gmail.com> writes:
>> 
>>> Excerpts from Christophe Leroy's message of December 9, 2021 8:22 pm:
>>>>
>>>>
>>>> Le 09/12/2021 à 11:15, Nicholas Piggin a écrit :
>>>>> Excerpts from Christophe Leroy's message of December 9, 2021 3:18 am:
>>>>>> Select CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT and
>>>>>> remove arch/powerpc/mm/mmap.c
>>>>>>
>>>>>> This change provides standard randomisation of mmaps.
>>>>>>
>>>>>> See commit 8b8addf891de ("x86/mm/32: Enable full randomization on i386
>>>>>> and X86_32") for all the benefits of mmap randomisation.
>>>>>
>>>>> The justification seems pretty reasonable.
>>>>>
>>>>>>
>>>>>> Comparison between powerpc implementation and the generic one:
>>>>>> - mmap_is_legacy() is identical.
>>>>>> - arch_mmap_rnd() does exactly the same allthough it's written
>>>>>> slightly differently.
>>>>>> - MIN_GAP and MAX_GAP are identical.
>>>>>> - mmap_base() does the same but uses STACK_RND_MASK which provides
>>>>>> the same values as stack_maxrandom_size().
>>>>>> - arch_pick_mmap_layout() is almost identical. The only difference
>>>>>> is that it also adds the random factor to mm->mmap_base in legacy mode.
>>>>>>
>>>>>> That last point is what provides the standard randomisation of mmaps.
>>>>>
>>>>> Thanks for describing it. Could you add random_factor to mmap_base for
>>>>> the legacy path for powerpc as a 2-line change that adds the legacy
>>>>> randomisation. And then this bigger patch would be closer to a no-op.
>>>>>
>>>>
>>>> You mean you would like to see the following patch before doing the
>>>> convert ?
>>>>
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/7dabf1cbde67a346a187881d4f0bd17347e0334a.1533732583.git.christophe.leroy@c-s.fr/
>>>
>>> Yes.
>> 
>> My comment at the time was:
>> 
>>    Basically mmap_is_legacy() tells you if any of these is true:
>>    
>>     - process has the ADDR_COMPAT_LAYOUT personality
>>     - global legacy_va_layout sysctl is enabled
>>     - stack is unlimited
>> 
>>    And we only want to change the behaviour for the stack. Or at least the
>>    change log of your patch only talks about the stack limit, not the
>>    others.
>>    
>>    Possibly we should just enable randomisation for all three of those
>>    cases, but if so we must spell it out in the patch.
>>    
>>    It'd also be good to see the output of /proc/x/maps for some processes
>>    before and after, to show what actually changes.
>> 
>> 
>> From: https://github.com/linuxppc/issues/issues/59#issuecomment-502066947
>> 
>> 
>> So I think at least the change log on that patch still needs updating to
>> be clear that it's changing behaviour for all mmap_is_legacy() cases,
>> not just the stack unlimited case.
>> 
>> There's also a risk changing the mmap legacy behaviour breaks something.
>> But we are at least matching the behaviour of other architectures, and
>> there is also an escape hatch in the form of `setarch -R`.
>
> That was the purpose of adding in the change log a reference to commit 
> 8b8addf891de ("x86/mm/32: Enable full randomization on i386
> and X86_32")
>
> All this applies to powerpc as well.

Yeah, I'm just a pessimist :) So although the security benefit is nice,
I'm more worried that the layout change will break some mission critical
legacy app somewhere. So I just like to have that spelled out in the
change log, or at least in the discussion like here.

> But I can copy paste the changelog of that commit into mine if you think 
> it is more explicit.

Just referring to it is probably fine.

> I agree that old patch was only refering to stack limit, I had no clue 
> of everything else at that time.

No worries.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Nicholas Piggin <npiggin@gmail.com>,
	"alex@ghiti.fr" <alex@ghiti.fr>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v4 09/10] powerpc/mm: Convert to default topdown mmap layout
Date: Fri, 10 Dec 2021 10:56:11 +1100	[thread overview]
Message-ID: <87r1almixw.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <7990b457-0b16-b4fb-d279-89a4cdc093a7@csgroup.eu>

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 09/12/2021 à 12:22, Michael Ellerman a écrit :
>> Nicholas Piggin <npiggin@gmail.com> writes:
>> 
>>> Excerpts from Christophe Leroy's message of December 9, 2021 8:22 pm:
>>>>
>>>>
>>>> Le 09/12/2021 à 11:15, Nicholas Piggin a écrit :
>>>>> Excerpts from Christophe Leroy's message of December 9, 2021 3:18 am:
>>>>>> Select CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT and
>>>>>> remove arch/powerpc/mm/mmap.c
>>>>>>
>>>>>> This change provides standard randomisation of mmaps.
>>>>>>
>>>>>> See commit 8b8addf891de ("x86/mm/32: Enable full randomization on i386
>>>>>> and X86_32") for all the benefits of mmap randomisation.
>>>>>
>>>>> The justification seems pretty reasonable.
>>>>>
>>>>>>
>>>>>> Comparison between powerpc implementation and the generic one:
>>>>>> - mmap_is_legacy() is identical.
>>>>>> - arch_mmap_rnd() does exactly the same allthough it's written
>>>>>> slightly differently.
>>>>>> - MIN_GAP and MAX_GAP are identical.
>>>>>> - mmap_base() does the same but uses STACK_RND_MASK which provides
>>>>>> the same values as stack_maxrandom_size().
>>>>>> - arch_pick_mmap_layout() is almost identical. The only difference
>>>>>> is that it also adds the random factor to mm->mmap_base in legacy mode.
>>>>>>
>>>>>> That last point is what provides the standard randomisation of mmaps.
>>>>>
>>>>> Thanks for describing it. Could you add random_factor to mmap_base for
>>>>> the legacy path for powerpc as a 2-line change that adds the legacy
>>>>> randomisation. And then this bigger patch would be closer to a no-op.
>>>>>
>>>>
>>>> You mean you would like to see the following patch before doing the
>>>> convert ?
>>>>
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/7dabf1cbde67a346a187881d4f0bd17347e0334a.1533732583.git.christophe.leroy@c-s.fr/
>>>
>>> Yes.
>> 
>> My comment at the time was:
>> 
>>    Basically mmap_is_legacy() tells you if any of these is true:
>>    
>>     - process has the ADDR_COMPAT_LAYOUT personality
>>     - global legacy_va_layout sysctl is enabled
>>     - stack is unlimited
>> 
>>    And we only want to change the behaviour for the stack. Or at least the
>>    change log of your patch only talks about the stack limit, not the
>>    others.
>>    
>>    Possibly we should just enable randomisation for all three of those
>>    cases, but if so we must spell it out in the patch.
>>    
>>    It'd also be good to see the output of /proc/x/maps for some processes
>>    before and after, to show what actually changes.
>> 
>> 
>> From: https://github.com/linuxppc/issues/issues/59#issuecomment-502066947
>> 
>> 
>> So I think at least the change log on that patch still needs updating to
>> be clear that it's changing behaviour for all mmap_is_legacy() cases,
>> not just the stack unlimited case.
>> 
>> There's also a risk changing the mmap legacy behaviour breaks something.
>> But we are at least matching the behaviour of other architectures, and
>> there is also an escape hatch in the form of `setarch -R`.
>
> That was the purpose of adding in the change log a reference to commit 
> 8b8addf891de ("x86/mm/32: Enable full randomization on i386
> and X86_32")
>
> All this applies to powerpc as well.

Yeah, I'm just a pessimist :) So although the security benefit is nice,
I'm more worried that the layout change will break some mission critical
legacy app somewhere. So I just like to have that spelled out in the
change log, or at least in the discussion like here.

> But I can copy paste the changelog of that commit into mine if you think 
> it is more explicit.

Just referring to it is probably fine.

> I agree that old patch was only refering to stack limit, I had no clue 
> of everything else at that time.

No worries.

cheers


  reply	other threads:[~2021-12-09 23:56 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08 17:18 [PATCH v4 00/10] Convert powerpc to default topdown mmap layout Christophe Leroy
2021-12-08 17:18 ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 01/10] mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 02/10] mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-09  9:40   ` Nicholas Piggin
2021-12-09  9:40     ` Nicholas Piggin
2021-12-08 17:18 ` [PATCH v4 03/10] powerpc/mm: Move vma_mmu_pagesize() Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-09  9:36   ` Nicholas Piggin
2021-12-09  9:36     ` Nicholas Piggin
2021-12-08 17:18 ` [PATCH v4 04/10] powerpc/mm: Make slice specific to book3s/64 Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 05/10] powerpc/mm: Remove CONFIG_PPC_MM_SLICES Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 06/10] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-09  9:50   ` Nicholas Piggin
2021-12-09  9:50     ` Nicholas Piggin
2021-12-10 17:47     ` Christophe Leroy
2021-12-10 17:47       ` Christophe Leroy
2021-12-16 14:25     ` Christophe Leroy
2021-12-16 14:25       ` Christophe Leroy
2021-12-13 13:02   ` Michael Ellerman
2021-12-13 13:02     ` Michael Ellerman
2021-12-08 17:18 ` [PATCH v4 08/10] powerpc/mm: Move get_unmapped_area functions to slice.c Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 07/10] powerpc/mm: Use generic_hugetlb_get_unmapped_area() Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-09 10:02   ` Nicholas Piggin
2021-12-09 10:02     ` Nicholas Piggin
2021-12-16 17:13     ` Christophe Leroy
2021-12-16 17:13       ` Christophe Leroy
2021-12-16 17:13       ` Christophe Leroy
2021-12-16 18:55       ` Catalin Marinas
2021-12-16 18:55         ` Catalin Marinas
2021-12-16 18:55         ` Catalin Marinas
2021-12-08 17:18 ` [PATCH v4 09/10] powerpc/mm: Convert to default topdown mmap layout Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy
2021-12-09 10:15   ` Nicholas Piggin
2021-12-09 10:15     ` Nicholas Piggin
2021-12-09 10:22     ` Christophe Leroy
2021-12-09 10:22       ` Christophe Leroy
2021-12-09 10:43       ` Nicholas Piggin
2021-12-09 10:43         ` Nicholas Piggin
2021-12-09 11:22         ` Michael Ellerman
2021-12-09 11:22           ` Michael Ellerman
2021-12-09 11:32           ` Christophe Leroy
2021-12-09 11:32             ` Christophe Leroy
2021-12-09 23:56             ` Michael Ellerman [this message]
2021-12-09 23:56               ` Michael Ellerman
2021-12-16 14:27     ` Christophe Leroy
2021-12-16 14:27       ` Christophe Leroy
2021-12-08 17:18 ` [PATCH v4 10/10] powerpc/mm: Properly randomise mmap with slices Christophe Leroy
2021-12-08 17:18   ` Christophe Leroy

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=87r1almixw.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.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.