On 04/19/2014 02:33 AM, Prem Karat wrote:
Based on commit 1091458d09e1a (mmap randomization)
For 32-bit address spaces randomize within a
16MB space, for 64-bit within a 256MB space.
How was it tested (i.e. what workload did you run to verify that the
kernel still functions with this change)?
Signed-off-by: Prem Karat <pkarat@xxxxxxxxxx>
---
arch/mips/kernel/vdso.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index 0f1af58..b49c705 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -16,9 +16,11 @@
#include <linux/elf.h>
#include <linux/vmalloc.h>
#include <linux/unistd.h>
+#include <linux/random.h>
#include <asm/vdso.h>
#include <asm/uasm.h>
+#include <asm/processor.h>
/*
* Including <asm/unistd.h> would give use the 64-bit syscall numbers ...
@@ -67,7 +69,18 @@ subsys_initcall(init_vdso);
static unsigned long vdso_addr(unsigned long start)
{
- return STACK_TOP;
+ unsigned long offset = 0UL;
+
+ if (current->flags & PF_RANDOMIZE) {
+ offset = get_random_int();
+ offset = offset << PAGE_SHIFT;
+ if (TASK_IS_32BIT_ADDR)
+ offset &= 0xfffffful;
+ else
+ offset &= 0xffffffful;
+ }
+
+ return (STACK_TOP + offset);
How can you be sure this address doesn't collide with, or otherwise
interfere with, the stack?
Also, as mentioned by Sergei, run checkpatch.pl to catch obvious
stylistic problems before submitting patches.
Thanks,
David Daney
}
int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
