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

[Kostya Serebryany]

On Thu, May 7, 2015 at 2:24 AM, David Chisnall <csdavec at swan.ac.uk> wrote:

> A couple of high-level comments:
>
> I don't really like making this a sanitizer.  It is supposed to be useable
> in the same places stack canaries are used (i.e. in production, with a view
> to enabling it for 100% of code).  Making it an -fsanitize option makes it
> seem like a debugging tool, not a mitigation tool.
>

Disagree. We already have -fsanitize=cfi, which *is* a mitigation tool.
Having it as -fsanitize=* brings harmony and consistence (and reuses the
flag analysis code, which is not trivial).
Stack canaries are a joke (yes, sorry, it is a very weak protection) and
being similar to stack canaries is not a good thing by any account.


> I'm also not 100% convinced by the compiler-rt stuff.  This needs to be in
> libc.


Yes. If a given libc fully supports a feature X we simply do not link that
part of compiler-rt into the app.
This is a simple clang driver feature.
But we don't have it in any popular libc today and will not have it until
the tool proves to be useful.

--kcc


> What happens when a program dlopens libpthread?  The pthread_create symbol
> won't exist on library load, so it looks as if your interceptor code will
> just see a null pointer.  Then when the first thread is created, it will
> die horribly.
>
>
> http://reviews.llvm.org/D6096
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150507/14dbf9c3/attachment.html>