On Thu, May 7, 2015 at 2:24 AM, David Chisnall <[email protected]> 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/ > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
