i386/x86-64: Don't randomize stack top when...
PATCH 1/7 i386/x86-64: Don't randomize stack top when...
In-Reply-To: <44c514a8.6HlRR82y133O2bd0%[email protected]>
Quoted 12 lines · Andi Kleen
arch/i386/kernel/process.c +1
-0@@ -37,6 +37,7 @@#include <linux/kallsyms.h> #include <linux/ptrace.h> #include <linux/random.h> +#include <linux/personality.h> #include <asm/uaccess.h> #include <asm/pgtable.h>
arch/i386/kernel/process.c asmlinkage int sys_get_thread_area(struc · line 912
Quoted 8 lines
arch/i386/kernel/process.c +1
-1@@ -905,7 +906,7 @@ asmlinkage int sys_get_thread_area(strucunsigned long arch_align_stack (unsigned long sp) { -if (randomize_va_space) +if (!(current->personality &ADDR_NO_RANDOMIZE ) && randomize_va_space) sp -=get_random_int () %8192 ;return sp & ~0xf ; }
I think this needs to be done always, at least on P4. It really isn't 'randomization' at the same high level as the rest -- more like a small adjustment. And the offset should be a multiple of 128 and < 7K (not 8K.) Something like this:
unsigned int r = get_random_int();
sp &= ~0x7f;
sp -= 128 * ((r % 32) + (r / 32 % 16));
return sp;Signature · 1 line
Chuck
Quoted 16 lines · Chuck Ebbert
In-Reply-To: <44c514a8.6HlRR82y133O2bd0%[email protected]>
Quoted 13 lines · Andi Kleen
arch/i386/kernel/process.c +1
-0@@ -37,6 +37,7 @@#include <linux/kallsyms.h> #include <linux/ptrace.h> #include <linux/random.h> +#include <linux/personality.h> #include <asm/uaccess.h> #include <asm/pgtable.h> @@ -905,7 +906,7 @@ asmlinkage int sys_get_thread_area(struc
Quoted 12 lines
arch/i386/kernel/process.c asmlinkage int sys_get_thread_area(struc · line 912
Quoted 7 lines
arch/i386/kernel/process.c +1
-1unsigned long arch_align_stack (unsigned long sp) { -if (randomize_va_space) +if (!(current->personality &ADDR_NO_RANDOMIZE ) && randomize_va_space) sp -=get_random_int () %8192 ;return sp & ~0xf ; }I think this needs to be done always, at least on P4. It really isn't 'randomization' at the same high level as the rest -- more like a small adjustment. And the offset should be a multiple of 128 and < 7K (not 8K.) Something like this:
the 8K was what Intel proposed for 2.4 quite a while ago and has been in use in linux for years and years... Can you explain why you are saying 7Kb? throwing away that 1Kb of cache associativity is unfortunate and shouldn't be done unless there's a good reason, so I'm quite interested in finding out your reason ;)
Greetings,
Arjan van de Ven