3

I tried for fun to "improve" ASLR on my own x86 32-bit machine by modifying arch_align_stack() in process.c by increasing the second argument to modulo in:

if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
    sp -= get_random_int() % 8192;
return sp & ~0xf;

However I quickly discovered that tampering too much with this causes a kernel panic; and I suspect it makes the system unstable even just tampering somewhat with it (it survives on sheer luck for some time, most likely?).

This prompted me to ask a question about why this happens (original question at Why does the stack have to be page aligned?). Apparently this is because (as user "mpe" stated) the default stack size if 8 kiB, which is 8192 byte. So by extension increasing the stack size in the kernel, this argument (8192) should be possible to increase? It was also mentioned the location of the stack itself could be randomized.

Does Pax do this? If not, then why not?

How/where is the stack size specified in the kernel? Does this differ for 32-bit and 64-bit?

Is there any difference between 32-bit and 64-bit for this? Does 64-bit still use process.c for this stuff? I see that in process_64.c there is nothing that seems equivalent to this code.

Community
  • 1
  • 1
csstudent2233
  • 659
  • 10
  • 17

1 Answers1

3

Location of the stack is randomized even in vanilla kernel. Note that function load_elf_binary() invokes randomize_stack_top() which randomizes location of the stack. This function is the main part of Linux stack ASLR.

Good description of ASLR in Linux kernel can be found here. You probably will be interested mostly in section Stack Randomization.

Actually the main purpose of arch_align_stack() is to improve cache performance on CPU with HyperThreading or similar technologies. Moreover the value 8129 was not chosen because of stack size (kernel stack size is indeed 8K but this function is randomizing user stack address) but because of Intel recommendations. See this and this.

THREAD_SIZE specifies kernel stack size, it is 8K for both x86-32 and x86-64 as described here. User stack size is not fixed as the stack may grow unless it is limited by user.

arch/x86/kernel/process.c contains code common for both 32-bit and 64-bit. That's why there is no equivalent code in arch/x86/kernel/process_64.c (or arch/x86/kernel/process_32.c).

Paweł Dziepak
  • 2,062
  • 1
  • 16
  • 17