| 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
| ||
|
Message-ID: <Pine.LNX.4.64.0708150112120.29843@jikos.suse.cz>
Date: Wed, 15 Aug 2007 01:21:37 +0200 (CEST)
From: Jiri Kosina <jkosina@...e.cz>
To: Jakub Jelinek <jakub@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Roland McGrath <roland@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Ulrich Kunitz <kune@...ne-taler.de>,
Bret Towe <magnade@...il.com>, linux-kernel@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>,
Andi Kleen <ak@...e.de>
Subject: Re: [PATCH] [RESEND] PIE executable randomization
On Tue, 14 Aug 2007, Jiri Kosina wrote:
> It turned out recently that PIE-compiled binaries on x86_64, that
> perform larger amount of brk-allocations (for example bash) will not
> work (but they will work on ?86). This is because currently on ?86 the
> memory layout is as follows:
(Andi added to CC)
The following patch fixes the brk-allocation problems on x86_64 with code
randomization patch on PIE-compiled binaries. Is anyone aware of any
potential disaster it might cause somewhere please?
If not -- Andrew, could you apply it on top of
pie-executable-randomization.patch please? Thanks.
From: Jiri Kosina <jkosina@...e.cz>
X86_64: add flexmmap support
This patch adds flexible-mmap support for x86_64 and brings the address
space layout closer to the "new" i?86 address space layout. Using the
legacy layout is still possible by
- ADDR_COMPAT_LAYOUT personality
- having unlimited resource limit for stack
- legacy_va_layout sysctl setting
This corresponds to the ?86 behavior.
Flexible-mmap support is necessary for establishing proper mapping when
performing executable code randomization for PIE-compiled binaries,
otherwise non-randomized brk, which is immediately following the code,
might not have enough free space.
Signed-off-by: Jiri Kosina <jkosina@...e.cz>
arch/x86_64/mm/mmap.c | 107 ++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 92 insertions(+), 15 deletions(-)
diff --git a/arch/x86_64/mm/mmap.c b/arch/x86_64/mm/mmap.c
index 80bba0d..a5e658c 100644
--- a/arch/x86_64/mm/mmap.c
+++ b/arch/x86_64/mm/mmap.c
@@ -1,29 +1,106 @@
-/* Copyright 2005 Andi Kleen, SuSE Labs.
- * Licensed under GPL, v.2
+/*
+ * linux/arch/x86-64/mm/mmap.c
+ *
+ * flexible mmap layout support
+ *
+ * Based on code by Ingo Molnar and Andi Kleen, copyrighted
+ * as follows:
+ *
+ * Copyright 2003-2004 Red Hat Inc., Durham, North Carolina.
+ * All Rights Reserved.
+ * Copyright 2005 Andi Kleen, SuSE Labs.
+ * Copyright 2007 Jiri Kosina, SuSE Labs.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
*/
+
+#include <linux/personality.h>
#include <linux/mm.h>
-#include <linux/sched.h>
#include <linux/random.h>
+#include <linux/limits.h>
+#include <linux/sched.h>
#include <asm/ia32.h>
-/* Notebook: move the mmap code from sys_x86_64.c over here. */
+/*
+ * Top of mmap area (just below the process stack).
+ *
+ * Leave an at least ~128 MB hole.
+ */
+#define MIN_GAP (128*1024*1024)
+#define MAX_GAP (TASK_SIZE/6*5)
-void arch_pick_mmap_layout(struct mm_struct *mm)
+static inline unsigned long mmap_base(void)
+{
+ unsigned long gap = current->signal->rlim[RLIMIT_STACK].rlim_cur;
+
+ if (gap < MIN_GAP)
+ gap = MIN_GAP;
+ else if (gap > MAX_GAP)
+ gap = MAX_GAP;
+
+ return TASK_SIZE - (gap & PAGE_MASK);
+}
+
+static inline int mmap_is_legacy(void)
{
#ifdef CONFIG_IA32_EMULATION
- if (current_thread_info()->flags & _TIF_IA32)
- return ia32_pick_mmap_layout(mm);
+ if (test_thread_flag(TIF_IA32))
+ return 1;
#endif
- mm->mmap_base = TASK_UNMAPPED_BASE;
+
+ if (current->personality & ADDR_COMPAT_LAYOUT)
+ return 1;
+
+ if (current->signal->rlim[RLIMIT_STACK].rlim_cur == RLIM_INFINITY)
+ return 1;
+
+ return sysctl_legacy_va_layout;
+}
+
+/*
+ * This function, called very early during the creation of a new
+ * process VM image, sets up which VM layout function to use:
+ */
+void arch_pick_mmap_layout(struct mm_struct *mm)
+{
+ int rnd = 0;
if (current->flags & PF_RANDOMIZE) {
/* Add 28bit randomness which is about 40bits of address space
because mmap base has to be page aligned.
- or ~1/128 of the total user VM
- (total user address space is 47bits) */
- unsigned rnd = get_random_int() & 0xfffffff;
- mm->mmap_base += ((unsigned long)rnd) << PAGE_SHIFT;
+ or ~1/128 of the total user VM
+ (total user address space is 47bits) */
+ rnd = get_random_int() & 0xfffffff;
}
- mm->get_unmapped_area = arch_get_unmapped_area;
- mm->unmap_area = arch_unmap_area;
-}
+ /*
+ * Fall back to the standard layout if the personality
+ * bit is set, or if the expected stack growth is unlimited:
+ */
+ if (mmap_is_legacy()) {
+ mm->mmap_base = TASK_UNMAPPED_BASE;
+ mm->get_unmapped_area = arch_get_unmapped_area;
+ mm->unmap_area = arch_unmap_area;
+ } else {
+ mm->mmap_base = mmap_base();
+ mm->get_unmapped_area = arch_get_unmapped_area_topdown;
+ mm->unmap_area = arch_unmap_area_topdown;
+ if (current->flags & PF_RANDOMIZE)
+ rnd = -rnd;
+ }
+ if (current->flags & PF_RANDOMIZE) {
+ mm->mmap_base += ((long)rnd) << PAGE_SHIFT;
+ }
+}
-
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/
Powered by blists - more mailing lists