[PATCH] Protection against stack-based memory corruption errors using SafeStack: compiler-rt runtime support library

[Volodymyr Kuznetsov]

You can find the detailed changelog since the previous submission in our repo: https://github.com/cpi-llvm/compiler-rt/commits/safestack-r221153

================
Comment at: lib/safestack/safestack.cc:51
@@ +50,3 @@
+
+// The unsafe stack pointer is stored in the TCB structure on these platforms
+#if defined(__i386__)
----------------
theraven wrote:
> kcc wrote:
> >  I might be missing something, but can't we just use TLS to store the second stack? 
> C11 TLS does not have a way of attaching destructors.  C++11 does (although the standard is undefined in the presence of shared library loading and unloading, which makes it less useful), but does not have any way of ordering the destruction.
The main reason of putting the unsafe stack pointer in the tcb directly is performance: that way, the unsafe stack pointer can be loaded/stored with just one memory access. It's exactly the same optimization as the existing stack protector uses (see X86TargetLowering::getStackCookieLocation in X86ISelLowering.cpp:1925).

Following David's suggestion, I will remove this optimization on Linux for now, until it can be properly implemented on the glibc side as well. I plan to only keep it on Darwin (where it seems to be cleaner, as I will explain in the comments). I will use TLS for unsafe_stack_(start|size|guard) on all platforms, as those are not performance critical in any way.

http://reviews.llvm.org/D6096