<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 11:14 AM, Volodymyr Kuznetsov <span dir="ltr"><<a href="mailto:vova.kuznetsov@epfl.ch" target="_blank">vova.kuznetsov@epfl.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi Kostya,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your comments! We are great fans of AddressSanitizer ourselves, we use it extensively and also plan to contribute to it in the future as well.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Our understanding is that ASAN's main use case is during testing; the goal of SafeStack is to run in production, so it therefore offers a specific form of protection that can be delivered at near-zero overhead. In particular, we don't focus much on bug detection, but rather on making it much harder to write exploits against code that has bugs. With the SafeStack enabled, the distance between on-stack buffer that might overflow and the return addresses (or sensitive spilled registers) that the attacker might want to overwrite becomes much less predictable (or even randomized, if ASLR is employed), as they're now stored on two separate stacks.</div></div></blockquote><div><br></div><div>No disagreement here. </div><div>We do want to use asan in production (and we have some results!) but asan's overhead will remain much higher than SafeStack's. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Our current SafeStack implementation is just a first step in that direction. In the future, we plan to further protect the regular stack using leak-proof randomization (as described in our paper): the regular stack will be allocated at a random offset and the instrumentation will ensure that neither %rsp value nor any other pointers to the regular stack would ever be stored on the heap or on the unsafe stack. This would mostly require changes to the libc/glibc to instrument setjmp/longjmp, stack unwinding, and other code that accesses %rsp directly. With such protection in place, overwriting the return addresses or pivoting the stack would become nearly impossible in practice, along with many ROP attacks that are based on it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Please find answers to some of your specific questions below:</div><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 4 Nov 2014, at 00:36, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br></span><span class=""><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Hi Volodymyr,

disclaimer: my opinion is biased because I've co-authored AddressSanitizer
and SafeStack is doing very similar things.

The functionality of SafeStack is limited in scope, but given the near-zero
overhead and non-zero benefits I'd still like to see it in LLVM trunk.
SafeStack, both the LLVM and compiler-rt parts, is very similar to what we
do in AddressSanitizer, so I would like to see more code reuse, especially
in compiler-rt.</pre></span></span></blockquote><div>That would be great indeed and could simplify the SafeStack code in several places. We will try to figure our how to do it without increasing the overhead or complexity of the SafeStack (e.g., without requiring to link with pthreads, etc.).</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">What about user-visible interface? Do we want it to be more similar to
asan/tsan/msan/lsan/ubsan/dfsan flags, e.g. -fsanitize=safe-stack ?</pre></span></blockquote></span><div>We've picked the -fsafe-stack option as it feels more similar to -fstack-protector option, whose usage model we follow. The -fsanitize options feel more associated with testing/debugging than the production use (or at least we perceive it this way).</div></div></div></div></blockquote><div>I have no strong opinion here.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">I am puzzled why you are doing transformations on the CodeGen level, as
opposed to doing it in LLVM IR pass.</pre></span></blockquote></span><div>As I explained on Phabricator, we want to apply the SafeStack transformation as the very last step before code generation, to make sure that it operate on the final stack layout. Doing so earlier might prevent some other optimizations from succeeding (as it e.g., complicates the alias analysis, breaks mem2reg pass, etc.) or might force the SafeStack pass move more objects to the unsafe stack than necessary (e.g., if the operations on such objects that the SafeStack considered potentially unsafe are actually later optimized away). In principle, in some pathological cases, it might even break correctness, e.g., if the SafeStack decides to keep some object on the normal stack, but the subsequent optimization or instrumentation passes add potentially unsafe operations on such objects.</div></div></div></div></blockquote><div><br></div><div>asan instrumentation is happening at the very end of the optimization chain and effectively we achieve what you need (run after all optimizations).</div><div>I would still suggest you to at least explore such possibility.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">LLVM code base is c++11 now, so in the new code please use c++11, at least
where it leads to simpler code (e.g. "for" loops).</pre></span></blockquote></span><div>Great point! I've fixed the code to use c++11 (along with many other issues raised on the Phabricator) and will update the patch ASAP.</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">compiler-rt part lacks tests. same for clang part.</pre></span></blockquote></span><div>Yes, we plan to eventually add such tests in the future.</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Are you planing to support this feature in LLVM long term?</pre></span></blockquote></span><div>We certainly want to see SafeStack used in the real world and will do our best to support it in LLVM. That said, please keep in mind that we're just a small group in a research institution with very limited resources, so we hardly can make any promises and would greatly appreciate any help from the community on supporting and improving the SafeStack.</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">You say that SafeStack is a superset of stack cookies.
What are the downsides?
You at least increase the memory footprint by doubling the stack sizes.
You also add some (minor) incompatibility and the need for the new
attributes to disable SafeStack.
What else?</pre></span></blockquote><div>Please see <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078475.html" target="_blank">an earlier email</a> for a discussion of the memory footprint. The main (minor) incompatibility that we observed were related to the mark-and-sweep garbage collection implementation for C++ that we saw in Chromuim: we had to change it to scan the unsafe stack as well (in addition to the regular stack) when searching for pointers to the heap. The change was rather small and well isolated though, and pretty much aligned with already existing support for AddressSanitizer in that garbage collector.</div></div></div></div></blockquote><div><br></div><div>I wonder if SafeStack can hook into the existing asan<=>gc interface?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><pre style="white-space:pre-wrap;color:rgb(0,0,0)">I've also left a few specific comments in phabricator.</pre></span></blockquote></span><div>Thank you for the comments! We plan to submit the updated patch ASAP.</div><span class=""><font color="#888888"><div><br></div><div>- Volodymyr Kuznetsov</div></font></span></div></div></div>
</blockquote></div><br></div></div>