[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ASLR still problematic with -lpthread
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
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.
Main Index |
Thread Index |