<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 15, 2014 at 4:53 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">Hi Kostya,<br>
<span class=""><br>
>On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at <a href="http://epfl.ch" target="_blank">epfl.ch</a><br>
>> wrote:<br>
><br>
>> Dear LLVM developers,<br>
>><br>
>> We've applied the feedback we received on Phabricator on the SafeStack<br>
>> patches,<br>
>><br>
><br>
</span><span class="">>Did you investigate the possibility of moving the transformation from<br>
>codegen to the LLVM level, i.e. the same level where asan/msan/tsan/dfsan<br>
>work?<br>
>I understand that it's a lot of work, but it will pay off with greater<br>
>portability and maintainability later.<br>
<br>
</span>We're currently considering doing something in-between. We could place<br>
the SafeStack pass in lib/Transformation/Instrumentation, so that it<br>
can be easily invoked with opt and operate on IR, but still schedule<br>
the pass during code generation by default.<br>
<br>
The latter is especially important when using LTO: running SafeStack<br>
before LTO would both impair the effectiveness of LTO (e.g., by<br>
breaking alias analysis, mem2reg, etc), and prevent SafeStack from<br>
taking advantage of the extra information obtained during LTO (e.g.,<br>
LTO can remove some pointer uses through inlining and DCE, etc.). Even<br>
without LTO, some of the passes scheduled during code generation (in<br>
addPassesToGenerateCode) could affect the security and the performance<br>
of the generated code as well.<br></blockquote><div><br></div><div><br></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">
<br>
Do you think moving the pass to lib/Transform/Instrumentation but<br>
scheduling it during code generation would make sense ? If so, we'll<br>
do that and change the safestack tests to use opt instead of llc.<br></blockquote><div><br></div><div>I think this should be doable, however I am not an expert in the pass manager and LTO, hopefully someone else can comment. </div><div>Nick?</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">
<span class=""><br>
>Also, did you reply to my comments about reusing compiler-rt code from<br>
>sanitizer_common?<br>
>I see lots of places in lib/safestack where you duplicate existing<br>
>functionality from lib/sanitizer_common<br>
<br>
</span>Yes, we would like to use some of the functions from sanitizer_common<br>
(e.g., internal_mmap/munmap and some pthread-related functions), but<br>
linking the entire sanitizer_common just for that might be an<br>
overkill. E.g., it can make small programs like coreutils up to 3x<br>
larger, and it requires compiling with -pthread. Perhaps we can move<br>
those functions to separate files in sanitizer_common and make them<br>
usable independently from the rest of sanitizer_common?<br></blockquote><div><br></div><div>Clearly. </div><div>samsonov@ would know more about splitting sanitizer_common into pieces, </div><div>he has already done similar things. </div><div><br></div><div>--kcc </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">
<br>
- Vova<br>
<div class=""><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>