+++ /dev/null
-From tixy@linaro.org Mon May 16 16:59:23 2016
-From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
-Date: Tue, 10 May 2016 18:20:18 +0100
-Subject: arm64: Make arch_randomize_brk avoid stack area
-To: stable@vger.kernel.org
-Cc: Catalin Marinas <catalin.marinas@arm.com>, Kees Cook <keescook@chromium.org>
-Message-ID: <1462900818.3220.14.camel@linaro.org>
-
-
-From: Jon Medhurst <tixy@linaro.org>
-
-[As mentioned in the commit message, the problem this patch fixes can't
-occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later.,
-but earlier kernel versions need this fix.]
-
-When a process is created, various address randomisations could end up
-colluding to place the address of brk in the stack memory. This would
-mean processes making small heap based memory allocations are in danger
-of having them overwriting, or overwritten by, the stack.
-
-Another consequence, is that even for processes that make no use of
-brk, the output of /proc/*/maps may show the stack area listed as
-'[heap]' rather than '[stack]'. Apart from being misleading this causes
-fatal errors with the Android run-time like:
-"No [stack] line found in /proc/self/task/*/maps"
-
-To prevent this problem pick a limit for brk that allows for the stack's
-memory. At the same time we remove randomize_base() as that was only
-used by arch_randomize_brk().
-
-Note, in practice, since commit d1fd836dcf00 ("mm: split ET_DYN ASLR
-from mmap ASLR") this problem shouldn't occur because the address chosen
-for loading binaries is well clear of the stack, however, prior to that
-the problem does occur because of the following...
-
-The memory layout of a task is determined by arch_pick_mmap_layout. If
-address randomisation is enabled (task has flag PF_RANDOMIZE) this sets
-mmap_base to a random address at the top of task memory just below a
-region calculated to allow for a stack which itself may have a random
-base address. Any mmap operations that then happen which require an
-address allocating will use the topdown allocation method, i.e. the
-first allocated memory will be at the top of memory, just below the
-area set aside for the stack.
-
-When a relocatable binary is loaded into a new process by
-load_elf_binary and randomised address are enabled, it uses a
-'load_bias' of zero, so that when mmap is called to create a memory
-region for it, a new address is picked (address zero not being
-available). As this is the first memory region in the task, it gets the
-region just below the stack, as described previously.
-
-The loader then set's brk to the end of the elf data section, which will
-be near the end of the loaded binary and then it calls
-arch_randomize_brk. As this currently stands, this adds a random amount
-to brk, which unfortunately may take it into the address range where the
-stack lies.
-
-Testing:
-
-These changes have been tested on Linux 3.18 (where the collision of brk
-and stack can happen) using 100000 invocations of a program [1] that can
-display the offset of a process's brk...
-
-$for i in $(seq 100000); do ./aslr --report brk ; done
-
-This shows values of brk are evenly distributed over a 1GB range before
-this change is applied. After this change the distribution shows a slope
-where lower values for brk are more common and upper values have about
-half the frequency of those.
-
-[1] http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/2499/scripts/kernel-security/aslr/
-
-Signed-off-by: Jon Medhurst <tixy@linaro.org>
-Acked-by: Kees Cook <keescook@chromium.org>
-Acked-by: Catalin Marinas <catalin.marinas@arm.com>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----
-
-
-I originally posted this to the ARM kernel list and arm64 maintainers,
-see http://www.spinics.net/lists/arm-kernel/msg502238.html
-
- arch/arm64/kernel/process.c | 24 ++++++++++++++++++------
- 1 file changed, 18 insertions(+), 6 deletions(-)
-
---- a/arch/arm64/kernel/process.c
-+++ b/arch/arm64/kernel/process.c
-@@ -350,15 +350,27 @@ unsigned long arch_align_stack(unsigned
- return sp & ~0xf;
- }
-
--static unsigned long randomize_base(unsigned long base)
-+unsigned long arch_randomize_brk(struct mm_struct *mm)
- {
-+ unsigned long base = mm->brk;
- unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1;
-- return randomize_range(base, range_end, 0) ? : base;
--}
-+ unsigned long max_stack, range_limit;
-
--unsigned long arch_randomize_brk(struct mm_struct *mm)
--{
-- return randomize_base(mm->brk);
-+ /*
-+ * Determine how much room we need to leave available for the stack.
-+ * We limit this to a reasonable value, because extremely large or
-+ * unlimited stacks are always going to bump up against brk at some
-+ * point and we don't want to fail to randomise brk in those cases.
-+ */
-+ max_stack = rlimit(RLIMIT_STACK);
-+ if (max_stack > SZ_128M)
-+ max_stack = SZ_128M;
-+
-+ range_limit = mm->start_stack - max_stack - 1;
-+ if (range_end > range_limit)
-+ range_end = range_limit;
-+
-+ return randomize_range(base, range_end, 0) ? : base;
- }
-
- unsigned long randomize_et_dyn(unsigned long base)
projects / thirdparty / kernel / stable-queue.git / commitdiff
