Re: How to mitigate affect of reducing PAX_ASLR_DELTA_STACK_LSB to 2

[christos%astron.com@localhost (Christos Zoulas)]

In article <CA+5s4_JUFg_ZTdNjx8gtY1y90bJEB0i-hKhBwJoMBeQJ+AcHeQ%mail.gmail.com@localhost>,
Ripunjay Tripathi  <ripunjay.tripathi%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>To understand the ASLR and its impact on application address space I
>modified the NetBSD kern_pax.c code as below. My line of thought is to
>increase entropy by bringing in lower bytes into play. Original PAX code
>causes stack to be page aligned and jumps from page to page under different
>invocations. I just added that we move on to specific word aligned memory.
>Since in most applications the first few frames will be used less as
>compared to the ones on top, the performance should not be too much of an
>issue (it is just an assumption).
>
>#define PAX_ASLR_DELTA_STACK_LSB    PGSHIFT
>#define PAX_ASLR_DELTA(delta, lsb, len) \
>
>    (((delta) & ((1UL << (len)) - 1)) << (lsb))
>
>I modified it as
>
>#define PAX_ASLR_DELTA_STACK_LSB     2
>
>Variable delta is output from arc4random() function. Variable len is number
>of bits we wants to randomize.
>
>The randomized value we get as above is added to address where stack was
>allocated initially by kernel.
>
>When I tried this init crashed for ENOMEM.
>
>I wanted to take expert opinion on how can I succeed in doing this and does
>it actually brings any benefit about randomization, also if the performance
>penalty is prohibitive.

Yes, it would be a lot better if we could have more bits to randomize.
The problem is that if you don't make things multiple of the page size,
eventually the VM system will round it for you since it can only handle
allocations with page size granularity....

The other way to do this would be to randomly adjust the stack start after
it has been allocated by the vm system...

christos