linux-kernel - [PATCH RFC] fs/binfmt_elf: fix memory map for PIE applications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1380698395-5784-1-git-send-email-timo.teras@iki.fi>
Date:	Wed,  2 Oct 2013 10:19:55 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Kosina <jkosina@...e.cz>
Cc:	Timo Teräs <timo.teras@....fi>
Subject: [PATCH RFC] fs/binfmt_elf: fix memory map for PIE applications

arch/*/include/asm/elf.h comments say:
  ELF_ET_DYN_BASE 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.

In case we have main application linked as PIE, this can cause
problems as the main program itself is being loaded to this
alternate address. And this allows limited heap size. While
this is inevitable when exec'ing the interpreter directly,
we should do better for PIE applications.

This fixes the loader to detect PIE application by checking if
elf_interpreter is requested. This images are loaded to beginning
of the address space instead of the specially crafted place for elf
interpreter. This allows full heap address space for PIE applications
and fixes random "out of memory" errors.

Signed-off-by: Timo Teräs <timo.teras@....fi>
---
 fs/binfmt_elf.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

It might make sense to define ELF_ET_DYN_APP_BASE or similar
so that architectures can specify the load address of ET_DYN
applications.

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 100edcc..f1508c7 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -802,21 +802,19 @@ static int load_elf_binary(struct linux_binprm *bprm)
 			 * default mmap base, as well as whatever program they
 			 * might try to exec.  This is because the brk will
 			 * follow the loader, and is not movable.  */
+			if (elf_interpreter)
+				load_bias = 0x00400000UL;
+			else
+				load_bias = ELF_ET_DYN_BASE;
 #ifdef CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE
 			/* Memory randomization might have been switched off
 			 * in runtime via sysctl or explicit setting of
 			 * personality flags.
-			 * If that is the case, retain the original non-zero
-			 * load_bias value in order to establish proper
-			 * non-randomized mappings.
 			 */
 			if (current->flags & PF_RANDOMIZE)
-				load_bias = 0;
-			else
-				load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);
-#else
-			load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);
+				load_bias += (get_random_int() & STACK_RND_MASK) << PAGE_SHIFT;
 #endif
+			load_bias = ELF_PAGESTART(vaddr + load_bias);
 		}

 		error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
-- 
1.8.4

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