Re: ASLR still problematic with -lpthread

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

In article <20100909214844.GA21381%britannica.bec.de@localhost>,
Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
>On Thu, Sep 09, 2010 at 09:43:09PM +0000, Christos Zoulas wrote:
>> Here's the disgusting fix; I am not going to even bother to explain it.
>
>Do we need this soonish? For many platforms the stack based code is
>going to disappear soon anyway.

I think that the current code works purely by chance. If the stack
base or the stack pointer happen to be in the wrong place, we'll
simply get a core dump.  As it is, I have not seen any coredumps
without having ASLR enabled. This code improves the situation,
but it is unclear to me if it is ok to do:

        base = (void *)(pthread__sp() & pthread__threadmask);

on machines where the stack grows up.
In the current scenario, we have 2 failure cases (no matter how the
stack grows) without my hack:

1. base < [main_stack_base]. Can happen if stack is for example
   main_stack_base = 0xbfe02000 and sp = 0xbfexxxxx.
   then base = 0xbfe00000 < 0xbfe02000 and when we try to write
   to 0xbfe00038 for example we get a instant core-dump.
   this is solved by the mprotect(2) part of the fix.
2. base is really close to pthread__sp(). Can happen if
   pthread__sp() ~= 0xbfe01000. then base becomes 0xbfe00000 and
   we fault when we try to write data on the stack, because of the
   redzone page that the stackid sets up. This is handled by growing
   the stack, and keeping track if we did that when we look for the
   thread structure.

I would really like it if the bogus stack handling code was ifdef'ed out
if we had TLS, so it would be clear what the new stack allocation code
would be. If it is the case that we are not going to have TLS for all
architectures for a while, someone needs to verify that I am correct
and commit something similar to my change.

christos