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

Groups > linux.kernel > #1672929 > unrolled thread

[PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE

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 3/4] powerpc: Reduce ELF_ET_DYN_BASE Kees Cook <keescook@chromium.org> - 2017-06-22 20:10 +0200
    Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE Michael Ellerman <mpe@ellerman.id.au> - 2017-06-23 09:10 +0200
      Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE Kees Cook <keescook@chromium.org> - 2017-06-23 22:10 +0200
        Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE Michael Ellerman <mpe@ellerman.id.au> - 2017-06-26 15:10 +0200
          Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE Kees Cook <keescook@chromium.org> - 2017-06-26 20:30 +0200

#1672929 — [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE

Now that explicitly executed loaders are loaded in the mmap region,
position PIE binaries lower in the address space to avoid possible
collisions with mmap or stack regions. For 64-bit, align to 4GB to
allow runtimes to use the entire 32-bit address space for 32-bit
pointers.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/powerpc/include/asm/elf.h | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 09bde6e34f5d..548d9a411a0d 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -23,12 +23,13 @@
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	PAGE_SIZE
 
-/* This is the location that an ET_DYN program is loaded if exec'ed.  Typical
-   use of this is to invoke "./ld.so someprog" to test out a new version of
-   the loader.  We need to make sure that it is out of the way of the program
-   that it will "exec", and that there is sufficient room for the brk.  */
-
-#define ELF_ET_DYN_BASE	0x20000000
+/*
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
+ */
+#define ELF_ET_DYN_BASE		(is_32bit_task() ? 0x000400000UL : \
+						   0x100000000UL)
 
 #define ELF_CORE_EFLAGS (is_elf2_task() ? 2 : 0)
 
-- 
2.7.4

[toc] | [next] | [standalone]

#1673305

Kees Cook <keescook@chromium.org> writes:

> Now that explicitly executed loaders are loaded in the mmap region,
> position PIE binaries lower in the address space to avoid possible
> collisions with mmap or stack regions. For 64-bit, align to 4GB to
> allow runtimes to use the entire 32-bit address space for 32-bit
> pointers.

The change log and subject are a bit out of whack with the actual patch
because previously we used 512MB.

How about?

  powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB
  
  Now that explicitly executed loaders are loaded in the mmap region,
  we have more freedom to decide where we position PIE binaries in the
  address space to avoid possible collisions with mmap or stack regions.
  
  For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
  address space for 32-bit pointers. On 32-bit use 4MB.


Is there any particular reasoning behind the 4MB value on 32-bit?


I gave this a quick spin and it booted OK on all my test boxes, which
covers 64-bit/32-bit kernel and userspace. So seems to work!

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

cheers

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

#1673810

On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> Now that explicitly executed loaders are loaded in the mmap region,
>> position PIE binaries lower in the address space to avoid possible
>> collisions with mmap or stack regions. For 64-bit, align to 4GB to
>> allow runtimes to use the entire 32-bit address space for 32-bit
>> pointers.
>
> The change log and subject are a bit out of whack with the actual patch
> because previously we used 512MB.
>
> How about?
>
>   powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB
>
>   Now that explicitly executed loaders are loaded in the mmap region,
>   we have more freedom to decide where we position PIE binaries in the
>   address space to avoid possible collisions with mmap or stack regions.
>
>   For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
>   address space for 32-bit pointers. On 32-bit use 4MB.

Good idea, thanks. I'll resend the series with the commit logs updated.

> Is there any particular reasoning behind the 4MB value on 32-bit?

So, I've dug around a bit on this, and I *think* the rationale is to
avoid mapping a possible 4MB page table entry when it won't be using
at least a portion near the lower end (NULL address area covered
blocked by mmap_min_addr). It seems to be mainly tradition, though.

> I gave this a quick spin and it booted OK on all my test boxes, which
> covers 64-bit/32-bit kernel and userspace. So seems to work!

Awesome, thanks for the testing!

> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>
> cheers

-Kees

-- 
Kees Cook
Pixel Security

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

#1674763

Kees Cook <keescook@chromium.org> writes:

> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Kees Cook <keescook@chromium.org> writes:
>>
>>> Now that explicitly executed loaders are loaded in the mmap region,
>>> position PIE binaries lower in the address space to avoid possible
>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to
>>> allow runtimes to use the entire 32-bit address space for 32-bit
>>> pointers.
>>
>> The change log and subject are a bit out of whack with the actual patch
>> because previously we used 512MB.
>>
>> How about?
>>
>>   powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB
>>
>>   Now that explicitly executed loaders are loaded in the mmap region,
>>   we have more freedom to decide where we position PIE binaries in the
>>   address space to avoid possible collisions with mmap or stack regions.
>>
>>   For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
>>   address space for 32-bit pointers. On 32-bit use 4MB.
>
> Good idea, thanks. I'll resend the series with the commit logs updated.
>
>> Is there any particular reasoning behind the 4MB value on 32-bit?
>
> So, I've dug around a bit on this, and I *think* the rationale is to
> avoid mapping a possible 4MB page table entry when it won't be using
> at least a portion near the lower end (NULL address area covered
> blocked by mmap_min_addr). It seems to be mainly tradition, though.

OK, that is obscure, especially for CPUs that don't have a 4MB page
size. But consistency across arches is probably best regardless.

cheers

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

#1674991

On Mon, Jun 26, 2017 at 6:04 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> On Fri, Jun 23, 2017 at 12:01 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Kees Cook <keescook@chromium.org> writes:
>>>
>>>> Now that explicitly executed loaders are loaded in the mmap region,
>>>> position PIE binaries lower in the address space to avoid possible
>>>> collisions with mmap or stack regions. For 64-bit, align to 4GB to
>>>> allow runtimes to use the entire 32-bit address space for 32-bit
>>>> pointers.
>>>
>>> The change log and subject are a bit out of whack with the actual patch
>>> because previously we used 512MB.
>>>
>>> How about?
>>>
>>>   powerpc: Move ELF_ET_DYN_BASE to 4GB / 4MB
>>>
>>>   Now that explicitly executed loaders are loaded in the mmap region,
>>>   we have more freedom to decide where we position PIE binaries in the
>>>   address space to avoid possible collisions with mmap or stack regions.
>>>
>>>   For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
>>>   address space for 32-bit pointers. On 32-bit use 4MB.
>>
>> Good idea, thanks. I'll resend the series with the commit logs updated.
>>
>>> Is there any particular reasoning behind the 4MB value on 32-bit?
>>
>> So, I've dug around a bit on this, and I *think* the rationale is to
>> avoid mapping a possible 4MB page table entry when it won't be using
>> at least a portion near the lower end (NULL address area covered
>> blocked by mmap_min_addr). It seems to be mainly tradition, though.
>
> OK, that is obscure, especially for CPUs that don't have a 4MB page
> size. But consistency across arches is probably best regardless.

Yeah, I like being not "close" to the NULL address, though the
definition of "close" has been various values like 64K (mmap_min_addr)
and 1M (x86 BIOS junk and new stack-gap size). 4MB is above even that,
so, I think we're fine there. It's what Windows has used, so it's
familiar and any new attack methodologies would at least be shared
across OSes and architectures, so we should "notice" any problem with
the value, and then we can adjust it if we need to.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web