Set the glibc thread's pointer_guard (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 12 Sep 2016 20:09:33 +0000 (16:09 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 16 Sep 2016 18:35:09 +0000 (14:35 -0400)
commit665417ee428b2c01f6617ec4a5c79938fe468879
tree45d142e5be73875a291dce75bb3623e3134e7f8b
parent2279485d8726658cabb9b1517ecd276e9d67fd07
Set the glibc thread's pointer_guard (XCC)

Every thread needs to have the same pointer_guard.  We inherit it from the
creating parent (TLS, really).  And while we're here, set the stack_guard
too.  This is what glibc does when it creates a pthread.

All threads must have the same pointer_guard.  The issue is that if a
thread other than thread0 sets an atexit() function pointer, then the
pointer gets mangled with the wrong pointer_guard value.  Then when thread0
exits, it will improperly demangle the value.

I considered just turning off pointer mangling, but this is fine as is.

Note that we set the pointer_guard on every TLS, not on every thread.  This
is fine.  Basically this is a global value that every context should see,
so it's fine for it to be in every TLS.  I think glibc doesn't really make
a distinction between TLS and threads; every TLS region has the glibc
thread struct sitting at fs:0, for instance.

I'm not sure why glibc didn't use a global.  Maybe it'd be easier for an
attacker to find the global than the TLS value (to do their own
demangling).  Though fs:0x30 is probably just as easy to find, and you
don't have to do any linking to find the global.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/tls.c
user/utest/atexit.c [new file with mode: 0644]