All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/4] Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 Kees Cook
  2017-06-22 18:06 ` [PATCH 1/4] arm: " Kees Cook
                   ` (3 more replies)
  0 siblings, 4 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

This is a follow-up to "binfmt_elf: Use ELF_ET_DYN_BASE only for PIE"[1],
which allow ELF_ET_DYN_BASE to be reduced from high in the address space.
That patch only changed x86, and this series changes arm, arm64, powerpc,
and s390.

Since these depend on the mentioned patch (which I'm hoping akpm will
pick up), I'm hoping to get arch-maintainer Acks for these (so they can
be carried all together).

Thanks!

-Kees

[1] https://patchwork.kernel.org/patch/9802387/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 0/4] Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 Kees Cook
  2017-06-22 18:06 ` [PATCH 1/4] arm: " Kees Cook
                   ` (3 more replies)
  0 siblings, 4 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

This is a follow-up to "binfmt_elf: Use ELF_ET_DYN_BASE only for PIE"[1],
which allow ELF_ET_DYN_BASE to be reduced from high in the address space.
That patch only changed x86, and this series changes arm, arm64, powerpc,
and s390.

Since these depend on the mentioned patch (which I'm hoping akpm will
pick up), I'm hoping to get arch-maintainer Acks for these (so they can
be carried all together).

Thanks!

-Kees

[1] https://patchwork.kernel.org/patch/9802387/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 0/4] Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 Kees Cook
  2017-06-22 18:06 ` [PATCH 1/4] arm: " Kees Cook
                   ` (3 more replies)
  0 siblings, 4 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: linux-arm-kernel

This is a follow-up to "binfmt_elf: Use ELF_ET_DYN_BASE only for PIE"[1],
which allow ELF_ET_DYN_BASE to be reduced from high in the address space.
That patch only changed x86, and this series changes arm, arm64, powerpc,
and s390.

Since these depend on the mentioned patch (which I'm hoping akpm will
pick up), I'm hoping to get arch-maintainer Acks for these (so they can
be carried all together).

Thanks!

-Kees

[1] https://patchwork.kernel.org/patch/9802387/

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 1/4] arm: Reduce ELF_ET_DYN_BASE
  2017-06-22 18:06 [PATCH 0/4] Reduce ELF_ET_DYN_BASE Kees Cook
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-22 18:06 ` [PATCH 2/4] arm64: " Kees Cook
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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.

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

diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index d2315ffd8f12..f13ae153fb24 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -112,12 +112,8 @@ int dump_task_regs(struct task_struct *t, elf_gregset_t *elfregs);
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* 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	(TASK_SIZE / 3 * 2)
+/* This is the base location for PIE (ET_DYN with INTERP) loads. */
+#define ELF_ET_DYN_BASE		0x400000UL
 
 /* When the program starts, a1 contains a pointer to a function to be 
    registered with atexit, as per the SVR4 ABI.  A value of 0 means we 
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 1/4] arm: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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.

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

diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index d2315ffd8f12..f13ae153fb24 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -112,12 +112,8 @@ int dump_task_regs(struct task_struct *t, elf_gregset_t *elfregs);
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* 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	(TASK_SIZE / 3 * 2)
+/* This is the base location for PIE (ET_DYN with INTERP) loads. */
+#define ELF_ET_DYN_BASE		0x400000UL
 
 /* When the program starts, a1 contains a pointer to a function to be 
    registered with atexit, as per the SVR4 ABI.  A value of 0 means we 
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 1/4] arm: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: linux-arm-kernel

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.

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

diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h
index d2315ffd8f12..f13ae153fb24 100644
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -112,12 +112,8 @@ int dump_task_regs(struct task_struct *t, elf_gregset_t *elfregs);
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* 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	(TASK_SIZE / 3 * 2)
+/* This is the base location for PIE (ET_DYN with INTERP) loads. */
+#define ELF_ET_DYN_BASE		0x400000UL
 
 /* When the program starts, a1 contains a pointer to a function to be 
    registered with atexit, as per the SVR4 ABI.  A value of 0 means we 
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
  2017-06-22 18:06 [PATCH 0/4] Reduce ELF_ET_DYN_BASE Kees Cook
  2017-06-22 18:06 ` [PATCH 1/4] arm: " Kees Cook
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-23  6:57   ` [kernel-hardening] " Ard Biesheuvel
  2017-06-22 18:06 ` [PATCH 3/4] powerpc: " Kees Cook
  2017-06-22 18:06 ` [PATCH 4/4] s390: " Kees Cook
  3 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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/arm64/include/asm/elf.h | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 5d1700425efe..f742af8f7c42 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -113,12 +113,13 @@
 #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.
+ * 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	(2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE		(test_thread_flag(TIF_32BIT) ?	\
+					0x000400000UL :		\
+					0x100000000UL)
 
 #ifndef __ASSEMBLY__
 
@@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
 
 #ifdef CONFIG_COMPAT
 
-#define COMPAT_ELF_ET_DYN_BASE		(2 * TASK_SIZE_32 / 3)
-
 /* AArch32 registers. */
 #define COMPAT_ELF_NGREG		18
 typedef unsigned int			compat_elf_greg_t;
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-23  6:57   ` [kernel-hardening] " Ard Biesheuvel
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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/arm64/include/asm/elf.h | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 5d1700425efe..f742af8f7c42 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -113,12 +113,13 @@
 #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.
+ * 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	(2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE		(test_thread_flag(TIF_32BIT) ?	\
+					0x000400000UL :		\
+					0x100000000UL)
 
 #ifndef __ASSEMBLY__
 
@@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
 
 #ifdef CONFIG_COMPAT
 
-#define COMPAT_ELF_ET_DYN_BASE		(2 * TASK_SIZE_32 / 3)
-
 /* AArch32 registers. */
 #define COMPAT_ELF_NGREG		18
 typedef unsigned int			compat_elf_greg_t;
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-23  6:57   ` [kernel-hardening] " Ard Biesheuvel
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: linux-arm-kernel

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/arm64/include/asm/elf.h | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 5d1700425efe..f742af8f7c42 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -113,12 +113,13 @@
 #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.
+ * 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	(2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE		(test_thread_flag(TIF_32BIT) ?	\
+					0x000400000UL :		\
+					0x100000000UL)
 
 #ifndef __ASSEMBLY__
 
@@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
 
 #ifdef CONFIG_COMPAT
 
-#define COMPAT_ELF_ET_DYN_BASE		(2 * TASK_SIZE_32 / 3)
-
 /* AArch32 registers. */
 #define COMPAT_ELF_NGREG		18
 typedef unsigned int			compat_elf_greg_t;
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
  2017-06-22 18:06 [PATCH 0/4] Reduce ELF_ET_DYN_BASE Kees Cook
  2017-06-22 18:06 ` [PATCH 1/4] arm: " Kees Cook
  2017-06-22 18:06 ` [PATCH 2/4] arm64: " Kees Cook
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-23  7:01     ` Michael Ellerman
  2017-06-23  7:01     ` Michael Ellerman
  2017-06-22 18:06 ` [PATCH 4/4] s390: " Kees Cook
  3 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-23  7:01     ` Michael Ellerman
  2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  2017-06-23  7:01     ` Michael Ellerman
  2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 4/4] s390: Reduce ELF_ET_DYN_BASE
  2017-06-22 18:06 [PATCH 0/4] Reduce ELF_ET_DYN_BASE Kees Cook
                   ` (2 preceding siblings ...)
  2017-06-22 18:06 ` [PATCH 3/4] powerpc: " Kees Cook
@ 2017-06-22 18:06 ` Kees Cook
  3 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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/s390/include/asm/elf.h | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
index e8f623041769..7c58d599f91b 100644
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -161,14 +161,13 @@ extern unsigned int vdso_enabled;
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* 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. 64-bit
-   tasks are aligned to 4GB. */
-#define ELF_ET_DYN_BASE (is_compat_task() ? \
-				(STACK_TOP / 3 * 2) : \
-				(STACK_TOP / 3 * 2) & ~((1UL << 32) - 1))
+/*
+ * 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_compat_task() ? 0x000400000UL : \
+						    0x100000000UL)
 
 /* This yields a mask that user programs can use to figure out what
    instruction set this CPU supports. */
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 4/4] s390: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

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/s390/include/asm/elf.h | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
index e8f623041769..7c58d599f91b 100644
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -161,14 +161,13 @@ extern unsigned int vdso_enabled;
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* 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. 64-bit
-   tasks are aligned to 4GB. */
-#define ELF_ET_DYN_BASE (is_compat_task() ? \
-				(STACK_TOP / 3 * 2) : \
-				(STACK_TOP / 3 * 2) & ~((1UL << 32) - 1))
+/*
+ * 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_compat_task() ? 0x000400000UL : \
+						    0x100000000UL)
 
 /* This yields a mask that user programs can use to figure out what
    instruction set this CPU supports. */
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 4/4] s390: Reduce ELF_ET_DYN_BASE
@ 2017-06-22 18:06 ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-22 18:06 UTC (permalink / raw)
  To: linux-arm-kernel

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/s390/include/asm/elf.h | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
index e8f623041769..7c58d599f91b 100644
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -161,14 +161,13 @@ extern unsigned int vdso_enabled;
 #define CORE_DUMP_USE_REGSET
 #define ELF_EXEC_PAGESIZE	4096
 
-/* 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. 64-bit
-   tasks are aligned to 4GB. */
-#define ELF_ET_DYN_BASE (is_compat_task() ? \
-				(STACK_TOP / 3 * 2) : \
-				(STACK_TOP / 3 * 2) & ~((1UL << 32) - 1))
+/*
+ * 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_compat_task() ? 0x000400000UL : \
+						    0x100000000UL)
 
 /* This yields a mask that user programs can use to figure out what
    instruction set this CPU supports. */
-- 
2.7.4

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
  2017-06-22 18:06 ` [PATCH 2/4] arm64: " Kees Cook
@ 2017-06-23  6:57   ` Ard Biesheuvel
  2017-06-23 13:52     ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23  6:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

Hi Kees,

On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
> 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/arm64/include/asm/elf.h | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 5d1700425efe..f742af8f7c42 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -113,12 +113,13 @@
>  #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.
> + * 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        (2 * TASK_SIZE_64 / 3)
> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
> +                                       0x000400000UL :         \
> +                                       0x100000000UL)
>

Why are you merging this with the COMPAT definition?

>  #ifndef __ASSEMBLY__
>
> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>
>  #ifdef CONFIG_COMPAT
>
> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
> -
>  /* AArch32 registers. */
>  #define COMPAT_ELF_NGREG               18
>  typedef unsigned int                   compat_elf_greg_t;
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  6:57   ` Ard Biesheuvel
  2017-06-23 13:52     ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23  6:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

Hi Kees,

On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
> 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/arm64/include/asm/elf.h | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 5d1700425efe..f742af8f7c42 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -113,12 +113,13 @@
>  #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.
> + * 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        (2 * TASK_SIZE_64 / 3)
> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
> +                                       0x000400000UL :         \
> +                                       0x100000000UL)
>

Why are you merging this with the COMPAT definition?

>  #ifndef __ASSEMBLY__
>
> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>
>  #ifdef CONFIG_COMPAT
>
> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
> -
>  /* AArch32 registers. */
>  #define COMPAT_ELF_NGREG               18
>  typedef unsigned int                   compat_elf_greg_t;
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  6:57   ` Ard Biesheuvel
  2017-06-23 13:52     ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23  6:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch

Hi Kees,

On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
> 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/arm64/include/asm/elf.h | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 5d1700425efe..f742af8f7c42 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -113,12 +113,13 @@
>  #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.
> + * 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        (2 * TASK_SIZE_64 / 3)
> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
> +                                       0x000400000UL :         \
> +                                       0x100000000UL)
>

Why are you merging this with the COMPAT definition?

>  #ifndef __ASSEMBLY__
>
> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>
>  #ifdef CONFIG_COMPAT
>
> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
> -
>  /* AArch32 registers. */
>  #define COMPAT_ELF_NGREG               18
>  typedef unsigned int                   compat_elf_greg_t;
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  6:57   ` Ard Biesheuvel
  2017-06-23 13:52     ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23  6:57 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Kees,

On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
> 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/arm64/include/asm/elf.h | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 5d1700425efe..f742af8f7c42 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -113,12 +113,13 @@
>  #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.
> + * 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        (2 * TASK_SIZE_64 / 3)
> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
> +                                       0x000400000UL :         \
> +                                       0x100000000UL)
>

Why are you merging this with the COMPAT definition?

>  #ifndef __ASSEMBLY__
>
> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>
>  #ifdef CONFIG_COMPAT
>
> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
> -
>  /* AArch32 registers. */
>  #define COMPAT_ELF_NGREG               18
>  typedef unsigned int                   compat_elf_greg_t;
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-23  7:01 UTC (permalink / raw)
  To: Kees Cook, Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, linux-kernel,
	linux-arch, kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-23  7:01 UTC (permalink / raw)
  To: Kees Cook, Andrew Morton
  Cc: Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, linux-kernel,
	linux-arch, kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-23  7:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Kees Cook, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, linux-kernel,
	linux-arch, kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-23  7:01 UTC (permalink / raw)
  To: Kees Cook, Andrew Morton
  Cc: Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, linux-kernel,
	linux-arch, kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23  7:01     ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-23  7:01 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
  2017-06-23  6:57   ` [kernel-hardening] " Ard Biesheuvel
@ 2017-06-23 13:52     ` Kees Cook
  2017-06-23 14:02       ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 13:52 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Hi Kees,
>
> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>> index 5d1700425efe..f742af8f7c42 100644
>> --- a/arch/arm64/include/asm/elf.h
>> +++ b/arch/arm64/include/asm/elf.h
>> @@ -113,12 +113,13 @@
>>  #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.
>> + * 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        (2 * TASK_SIZE_64 / 3)
>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>> +                                       0x000400000UL :         \
>> +                                       0x100000000UL)
>>
>
> Why are you merging this with the COMPAT definition?

It seemed like the right thing to do since a single definition could
handle both cases. Is there something I'm overlooking in the arm64
case?

-Kees

>
>>  #ifndef __ASSEMBLY__
>>
>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>
>>  #ifdef CONFIG_COMPAT
>>
>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>> -
>>  /* AArch32 registers. */
>>  #define COMPAT_ELF_NGREG               18
>>  typedef unsigned int                   compat_elf_greg_t;
>> --
>> 2.7.4
>>



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 13:52     ` Kees Cook
  2017-06-23 14:02       ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 13:52 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Hi Kees,
>
> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>> index 5d1700425efe..f742af8f7c42 100644
>> --- a/arch/arm64/include/asm/elf.h
>> +++ b/arch/arm64/include/asm/elf.h
>> @@ -113,12 +113,13 @@
>>  #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.
>> + * 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        (2 * TASK_SIZE_64 / 3)
>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>> +                                       0x000400000UL :         \
>> +                                       0x100000000UL)
>>
>
> Why are you merging this with the COMPAT definition?

It seemed like the right thing to do since a single definition could
handle both cases. Is there something I'm overlooking in the arm64
case?

-Kees

>
>>  #ifndef __ASSEMBLY__
>>
>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>
>>  #ifdef CONFIG_COMPAT
>>
>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>> -
>>  /* AArch32 registers. */
>>  #define COMPAT_ELF_NGREG               18
>>  typedef unsigned int                   compat_elf_greg_t;
>> --
>> 2.7.4
>>



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 13:52     ` Kees Cook
  2017-06-23 14:02       ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 13:52 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel

On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Hi Kees,
>
> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>> index 5d1700425efe..f742af8f7c42 100644
>> --- a/arch/arm64/include/asm/elf.h
>> +++ b/arch/arm64/include/asm/elf.h
>> @@ -113,12 +113,13 @@
>>  #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.
>> + * 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        (2 * TASK_SIZE_64 / 3)
>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>> +                                       0x000400000UL :         \
>> +                                       0x100000000UL)
>>
>
> Why are you merging this with the COMPAT definition?

It seemed like the right thing to do since a single definition could
handle both cases. Is there something I'm overlooking in the arm64
case?

-Kees

>
>>  #ifndef __ASSEMBLY__
>>
>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>
>>  #ifdef CONFIG_COMPAT
>>
>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>> -
>>  /* AArch32 registers. */
>>  #define COMPAT_ELF_NGREG               18
>>  typedef unsigned int                   compat_elf_greg_t;
>> --
>> 2.7.4
>>



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 13:52     ` Kees Cook
  2017-06-23 14:02       ` Kees Cook
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 13:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Hi Kees,
>
> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>> index 5d1700425efe..f742af8f7c42 100644
>> --- a/arch/arm64/include/asm/elf.h
>> +++ b/arch/arm64/include/asm/elf.h
>> @@ -113,12 +113,13 @@
>>  #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.
>> + * 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        (2 * TASK_SIZE_64 / 3)
>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>> +                                       0x000400000UL :         \
>> +                                       0x100000000UL)
>>
>
> Why are you merging this with the COMPAT definition?

It seemed like the right thing to do since a single definition could
handle both cases. Is there something I'm overlooking in the arm64
case?

-Kees

>
>>  #ifndef __ASSEMBLY__
>>
>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>
>>  #ifdef CONFIG_COMPAT
>>
>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>> -
>>  /* AArch32 registers. */
>>  #define COMPAT_ELF_NGREG               18
>>  typedef unsigned int                   compat_elf_greg_t;
>> --
>> 2.7.4
>>



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
  2017-06-23 13:52     ` Kees Cook
@ 2017-06-23 14:02       ` Kees Cook
  2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 14:02 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> Hi Kees,
>>
>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>> index 5d1700425efe..f742af8f7c42 100644
>>> --- a/arch/arm64/include/asm/elf.h
>>> +++ b/arch/arm64/include/asm/elf.h
>>> @@ -113,12 +113,13 @@
>>>  #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.
>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>> +                                       0x000400000UL :         \
>>> +                                       0x100000000UL)
>>>
>>
>> Why are you merging this with the COMPAT definition?
>
> It seemed like the right thing to do since a single definition could
> handle both cases. Is there something I'm overlooking in the arm64
> case?

And like 5 minutes later there was a loud head-slapping noise in my
office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
mode, so the merge isn't needed. Yes yes, I will split it back up and
drop the thread flag test.

Thanks!

-Kees

>>>  #ifndef __ASSEMBLY__
>>>
>>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>>
>>>  #ifdef CONFIG_COMPAT
>>>
>>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>>> -
>>>  /* AArch32 registers. */
>>>  #define COMPAT_ELF_NGREG               18
>>>  typedef unsigned int                   compat_elf_greg_t;
>>> --
>>> 2.7.4
>>>
>
>
>
> --
> Kees Cook
> Pixel Security



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 14:02       ` Kees Cook
  2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 14:02 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> Hi Kees,
>>
>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>> index 5d1700425efe..f742af8f7c42 100644
>>> --- a/arch/arm64/include/asm/elf.h
>>> +++ b/arch/arm64/include/asm/elf.h
>>> @@ -113,12 +113,13 @@
>>>  #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.
>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>> +                                       0x000400000UL :         \
>>> +                                       0x100000000UL)
>>>
>>
>> Why are you merging this with the COMPAT definition?
>
> It seemed like the right thing to do since a single definition could
> handle both cases. Is there something I'm overlooking in the arm64
> case?

And like 5 minutes later there was a loud head-slapping noise in my
office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
mode, so the merge isn't needed. Yes yes, I will split it back up and
drop the thread flag test.

Thanks!

-Kees

>>>  #ifndef __ASSEMBLY__
>>>
>>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>>
>>>  #ifdef CONFIG_COMPAT
>>>
>>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>>> -
>>>  /* AArch32 registers. */
>>>  #define COMPAT_ELF_NGREG               18
>>>  typedef unsigned int                   compat_elf_greg_t;
>>> --
>>> 2.7.4
>>>
>
>
>
> --
> Kees Cook
> Pixel Security



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 14:02       ` Kees Cook
  2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 14:02 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel

On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> Hi Kees,
>>
>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>> index 5d1700425efe..f742af8f7c42 100644
>>> --- a/arch/arm64/include/asm/elf.h
>>> +++ b/arch/arm64/include/asm/elf.h
>>> @@ -113,12 +113,13 @@
>>>  #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.
>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>> +                                       0x000400000UL :         \
>>> +                                       0x100000000UL)
>>>
>>
>> Why are you merging this with the COMPAT definition?
>
> It seemed like the right thing to do since a single definition could
> handle both cases. Is there something I'm overlooking in the arm64
> case?

And like 5 minutes later there was a loud head-slapping noise in my
office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
mode, so the merge isn't needed. Yes yes, I will split it back up and
drop the thread flag test.

Thanks!

-Kees

>>>  #ifndef __ASSEMBLY__
>>>
>>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>>
>>>  #ifdef CONFIG_COMPAT
>>>
>>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>>> -
>>>  /* AArch32 registers. */
>>>  #define COMPAT_ELF_NGREG               18
>>>  typedef unsigned int                   compat_elf_greg_t;
>>> --
>>> 2.7.4
>>>
>
>
>
> --
> Kees Cook
> Pixel Security



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 14:02       ` Kees Cook
  2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 1 reply; 52+ messages in thread
From: Kees Cook @ 2017-06-23 14:02 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> Hi Kees,
>>
>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>> index 5d1700425efe..f742af8f7c42 100644
>>> --- a/arch/arm64/include/asm/elf.h
>>> +++ b/arch/arm64/include/asm/elf.h
>>> @@ -113,12 +113,13 @@
>>>  #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.
>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>> +                                       0x000400000UL :         \
>>> +                                       0x100000000UL)
>>>
>>
>> Why are you merging this with the COMPAT definition?
>
> It seemed like the right thing to do since a single definition could
> handle both cases. Is there something I'm overlooking in the arm64
> case?

And like 5 minutes later there was a loud head-slapping noise in my
office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
mode, so the merge isn't needed. Yes yes, I will split it back up and
drop the thread flag test.

Thanks!

-Kees

>>>  #ifndef __ASSEMBLY__
>>>
>>> @@ -173,8 +174,6 @@ extern int arch_setup_additional_pages(struct linux_binprm *bprm,
>>>
>>>  #ifdef CONFIG_COMPAT
>>>
>>> -#define COMPAT_ELF_ET_DYN_BASE         (2 * TASK_SIZE_32 / 3)
>>> -
>>>  /* AArch32 registers. */
>>>  #define COMPAT_ELF_NGREG               18
>>>  typedef unsigned int                   compat_elf_greg_t;
>>> --
>>> 2.7.4
>>>
>
>
>
> --
> Kees Cook
> Pixel Security



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
  2017-06-23 14:02       ` Kees Cook
@ 2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 0 replies; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23 15:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

On 23 June 2017 at 14:02, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> Hi Kees,
>>>
>>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>>> index 5d1700425efe..f742af8f7c42 100644
>>>> --- a/arch/arm64/include/asm/elf.h
>>>> +++ b/arch/arm64/include/asm/elf.h
>>>> @@ -113,12 +113,13 @@
>>>>  #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.
>>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>>> +                                       0x000400000UL :         \
>>>> +                                       0x100000000UL)
>>>>
>>>
>>> Why are you merging this with the COMPAT definition?
>>
>> It seemed like the right thing to do since a single definition could
>> handle both cases. Is there something I'm overlooking in the arm64
>> case?
>
> And like 5 minutes later there was a loud head-slapping noise in my
> office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
> mode, so the merge isn't needed. Yes yes, I will split it back up and
> drop the thread flag test.
>

Oh, is that what I heard?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 0 replies; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23 15:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel, linux-arch, kernel-hardening

On 23 June 2017 at 14:02, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> Hi Kees,
>>>
>>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>>> index 5d1700425efe..f742af8f7c42 100644
>>>> --- a/arch/arm64/include/asm/elf.h
>>>> +++ b/arch/arm64/include/asm/elf.h
>>>> @@ -113,12 +113,13 @@
>>>>  #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.
>>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>>> +                                       0x000400000UL :         \
>>>> +                                       0x100000000UL)
>>>>
>>>
>>> Why are you merging this with the COMPAT definition?
>>
>> It seemed like the right thing to do since a single definition could
>> handle both cases. Is there something I'm overlooking in the arm64
>> case?
>
> And like 5 minutes later there was a loud head-slapping noise in my
> office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
> mode, so the merge isn't needed. Yes yes, I will split it back up and
> drop the thread flag test.
>

Oh, is that what I heard?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 0 replies; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23 15:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Martin Schwidefsky, Heiko Carstens, James Hogan, Pratyush Anand,
	Ingo Molnar, linux-arm-kernel, linuxppc-dev, linux-s390,
	linux-kernel

On 23 June 2017 at 14:02, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> Hi Kees,
>>>
>>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>>> index 5d1700425efe..f742af8f7c42 100644
>>>> --- a/arch/arm64/include/asm/elf.h
>>>> +++ b/arch/arm64/include/asm/elf.h
>>>> @@ -113,12 +113,13 @@
>>>>  #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.
>>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>>> +                                       0x000400000UL :         \
>>>> +                                       0x100000000UL)
>>>>
>>>
>>> Why are you merging this with the COMPAT definition?
>>
>> It seemed like the right thing to do since a single definition could
>> handle both cases. Is there something I'm overlooking in the arm64
>> case?
>
> And like 5 minutes later there was a loud head-slapping noise in my
> office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
> mode, so the merge isn't needed. Yes yes, I will split it back up and
> drop the thread flag test.
>

Oh, is that what I heard?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] [PATCH 2/4] arm64: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 15:04         ` Ard Biesheuvel
  0 siblings, 0 replies; 52+ messages in thread
From: Ard Biesheuvel @ 2017-06-23 15:04 UTC (permalink / raw)
  To: linux-arm-kernel

On 23 June 2017 at 14:02, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jun 23, 2017 at 6:52 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Jun 22, 2017 at 11:57 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> Hi Kees,
>>>
>>> On 22 June 2017 at 18:06, Kees Cook <keescook@chromium.org> wrote:
>>>> 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/arm64/include/asm/elf.h | 13 ++++++-------
>>>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
>>>> index 5d1700425efe..f742af8f7c42 100644
>>>> --- a/arch/arm64/include/asm/elf.h
>>>> +++ b/arch/arm64/include/asm/elf.h
>>>> @@ -113,12 +113,13 @@
>>>>  #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.
>>>> + * 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        (2 * TASK_SIZE_64 / 3)
>>>> +#define ELF_ET_DYN_BASE                (test_thread_flag(TIF_32BIT) ?  \
>>>> +                                       0x000400000UL :         \
>>>> +                                       0x100000000UL)
>>>>
>>>
>>> Why are you merging this with the COMPAT definition?
>>
>> It seemed like the right thing to do since a single definition could
>> handle both cases. Is there something I'm overlooking in the arm64
>> case?
>
> And like 5 minutes later there was a loud head-slapping noise in my
> office. Durr, yeah, arm64 doesn't have to deal with a "native 32-bit"
> mode, so the merge isn't needed. Yes yes, I will split it back up and
> drop the thread flag test.
>

Oh, is that what I heard?

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
  2017-06-23  7:01     ` Michael Ellerman
  (?)
@ 2017-06-23 20:08     ` Kees Cook
  2017-06-26 13:04         ` Michael Ellerman
  2017-06-26 13:04         ` Michael Ellerman
  -1 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-23 20:08 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 20:08     ` Kees Cook
  2017-06-26 13:04         ` Michael Ellerman
  2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-23 20:08 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 20:08     ` Kees Cook
  2017-06-26 13:04         ` Michael Ellerman
  2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-23 20:08 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 20:08     ` Kees Cook
  2017-06-26 13:04         ` Michael Ellerman
  2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-23 20:08 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-23 20:08     ` Kees Cook
  2017-06-26 13:04         ` Michael Ellerman
  2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 2 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-23 20:08 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-26 13:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-26 13:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-26 13:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-26 13:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-26 13:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 13:04         ` Michael Ellerman
  0 siblings, 0 replies; 52+ messages in thread
From: Michael Ellerman @ 2017-06-26 13:04 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 18:26           ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-26 18:26 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [kernel-hardening] Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 18:26           ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-26 18:26 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 18:26           ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-26 18:26 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 18:26           ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-26 18:26 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Andrew Morton, Russell King, Catalin Marinas, Will Deacon,
	Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
	Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
	linux-arm-kernel, linuxppc-dev, linux-s390, LKML, linux-arch,
	kernel-hardening

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

* [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
@ 2017-06-26 18:26           ` Kees Cook
  0 siblings, 0 replies; 52+ messages in thread
From: Kees Cook @ 2017-06-26 18:26 UTC (permalink / raw)
  To: linux-arm-kernel

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

^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2017-06-26 18:27 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-22 18:06 [PATCH 0/4] Reduce ELF_ET_DYN_BASE Kees Cook
2017-06-22 18:06 ` [PATCH 1/4] arm: " Kees Cook
2017-06-22 18:06 ` [PATCH 2/4] arm64: " Kees Cook
2017-06-23  6:57   ` [kernel-hardening] " Ard Biesheuvel
2017-06-23 13:52     ` Kees Cook
2017-06-23 14:02       ` Kees Cook
2017-06-23 15:04         ` Ard Biesheuvel
2017-06-22 18:06 ` [PATCH 3/4] powerpc: " Kees Cook
2017-06-23  7:01   ` Michael Ellerman
2017-06-23 20:08     ` Kees Cook
2017-06-23 20:08       ` Kees Cook
2017-06-23 20:08     ` Kees Cook
2017-06-26 13:04       ` Michael Ellerman
2017-06-26 18:26         ` Kees Cook
2017-06-26 18:26         ` Kees Cook
2017-06-26 18:26           ` Kees Cook
2017-06-26 13:04       ` Michael Ellerman
2017-06-26 13:04         ` Michael Ellerman
2017-06-23  7:01   ` Michael Ellerman
2017-06-23  7:01     ` Michael Ellerman
2017-06-22 18:06 ` [PATCH 4/4] s390: " Kees Cook

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.