3d917f4
From 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb Mon Sep 17 00:00:00 2001
3d917f4
From: Hector Marco-Gisbert <hecmargi@upv.es>
3d917f4
Date: Thu, 10 Mar 2016 20:51:00 +0100
3d917f4
Subject: [PATCH] x86/mm/32: Enable full randomization on i386 and X86_32
3d917f4
3d917f4
Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
3d917f4
the stack and the executable are randomized but not other mmapped files
3d917f4
(libraries, vDSO, etc.). This patch enables randomization for the
3d917f4
libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.
3d917f4
3d917f4
By default on i386 there are 8 bits for the randomization of the libraries,
3d917f4
vDSO and mmaps which only uses 1MB of VA.
3d917f4
3d917f4
This patch preserves the original randomness, using 1MB of VA out of 3GB or
3d917f4
4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.
3d917f4
3d917f4
The first obvious security benefit is that all objects are randomized (not
3d917f4
only the stack and the executable) in legacy mode which highly increases
3d917f4
the ASLR effectiveness, otherwise the attackers may use these
3d917f4
non-randomized areas. But also sensitive setuid/setgid applications are
3d917f4
more secure because currently, attackers can disable the randomization of
3d917f4
these applications by setting the ulimit stack to "unlimited". This is a
3d917f4
very old and widely known trick to disable the ASLR in i386 which has been
3d917f4
allowed for too long.
3d917f4
3d917f4
Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
3d917f4
personality flag, but fortunately this doesn't work on setuid/setgid
3d917f4
applications because there is security checks which clear Security-relevant
3d917f4
flags.
3d917f4
3d917f4
This patch always randomizes the mmap_legacy_base address, removing the
3d917f4
possibility to disable the ASLR by setting the stack to "unlimited".
3d917f4
3d917f4
Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
3d917f4
Acked-by: Ismael Ripoll Ripoll <iripoll@upv.es>
3d917f4
Acked-by: Kees Cook <keescook@chromium.org>
3d917f4
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
3d917f4
Cc: Linus Torvalds <torvalds@linux-foundation.org>
3d917f4
Cc: Peter Zijlstra <peterz@infradead.org>
3d917f4
Cc: Thomas Gleixner <tglx@linutronix.de>
3d917f4
Cc: akpm@linux-foundation.org
3d917f4
Cc: kees Cook <keescook@chromium.org>
3d917f4
Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.es
3d917f4
Signed-off-by: Ingo Molnar <mingo@kernel.org>
3d917f4
---
3d917f4
 arch/x86/mm/mmap.c | 14 +-------------
3d917f4
 1 file changed, 1 insertion(+), 13 deletions(-)
3d917f4
3d917f4
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
3d917f4
index 96bd1e2..389939f 100644
3d917f4
--- a/arch/x86/mm/mmap.c
3d917f4
+++ b/arch/x86/mm/mmap.c
3d917f4
@@ -94,18 +94,6 @@ static unsigned long mmap_base(unsigned long rnd)
3d917f4
 }
3d917f4
3d917f4
 /*
3d917f4
- * Bottom-up (legacy) layout on X86_32 did not support randomization, X86_64
3d917f4
- * does, but not when emulating X86_32
3d917f4
- */
3d917f4
-static unsigned long mmap_legacy_base(unsigned long rnd)
3d917f4
-{
3d917f4
-	if (mmap_is_ia32())
3d917f4
-		return TASK_UNMAPPED_BASE;
3d917f4
-	else
3d917f4
-		return TASK_UNMAPPED_BASE + rnd;
3d917f4
-}
3d917f4
-
3d917f4
-/*
3d917f4
  * This function, called very early during the creation of a new
3d917f4
  * process VM image, sets up which VM layout function to use:
3d917f4
  */
3d917f4
@@ -116,7 +104,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
3d917f4
 	if (current->flags & PF_RANDOMIZE)
3d917f4
 		random_factor = arch_mmap_rnd();
3d917f4
3d917f4
-	mm->mmap_legacy_base = mmap_legacy_base(random_factor);
3d917f4
+	mm->mmap_legacy_base = TASK_UNMAPPED_BASE + random_factor;
3d917f4
3d917f4
 	if (mmap_is_legacy()) {
3d917f4
 		mm->mmap_base = mm->mmap_legacy_base;
3d917f4
-- 
3d917f4
2.7.3
3d917f4