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

[Volodymyr Kuznetsov]

Hi David,

Thanks a lot for the review, your feedback is very valuable! We will apply
it and resubmit the patch as soon as possible.

Two of your points seem to be more challenging to me to address, given my
limited experience with the libc internals:

================
> Comment at: lib/safestack/safestack.cc:75
> @@ +74,3 @@
> +
> +// The following locations are platform-specific
> +# define __GET_UNSAFE_STACK_PTR()         (void*) __THREAD_GETMEM_L(0x280)
> ----------------
> There are magic numbers here again.  Please reference either an ABI
> document or equivalent that indicates that these are safe locations to use.
>

Do you know of any ABI documents that might be relevant to this? On
FreeBSD, we simply added corresponding fields to the tcb struct in libc
(in lib/libthr/arch/amd64/include/pthread_md.h). Do you think it would be
safer to use thread-local variables on Linux for now ? It would impact the
performance though. Perhaps in the future the glibc can be modified to add
the required fields to its tcb structure as well.


> ================
> Comment at: lib/safestack/safestack.cc:255
> @@ +254,3 @@
> +void thread_cleanup_handler(void* _iter) {
> +  // We want to free the unsafe stack only after all other destructors
> +  // have already run. We force this function to be called multiple times.
> ----------------
> This seems somewhat fragile.  It doesn't guarantee that the other
> destructors won't be run after this, only that they get several
> opportunities to run before.
>

Yes, I was worried about this as well. It worked in our tests, but can
certainly break in some cases. The clean solution is to perform this
cleanup in the pthread code itself, which is what we did on FreeBSD. We
hope it will eventually be added to glibc as well. Do you have any better
suggestions on how to handle this in the meantime?

Thanks!
- Vova
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141103/fcd3dfc2/attachment.html>