<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 24, 2013 at 10:32 PM, Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Static runtime will only intercept calls from the main executable, but<br>
> not from any libraries. This may work for simple standalone programs,<br>
> but you may run into puzzling failures.<br>
<br>
</div>What type of failures do you mean?  Does the symbol mismatch break<br>
assumptions in the ASan runtime?  It's easy to imagine, for example,<br>
ASan missing use-after-free bugs because the call to free() is in an<br>
uninstrumented shared library.  But would you expect<br>
stack-buffer-overflow and heap-buffer-overflow detection to work as<br>
expected?<br></blockquote><div><br></div><div>Malloc/free are special on Android - they are intercepted with bionic debug malloc hooks, which work fine with statically linked runtime.</div><div><br></div><div>One failure that I recall is related to initialization order. Libraries are initialized before the main executable, libc constructor calls malloc(), which we do not intercept because asan_init() has not run yet. Later we get a mismatching free(), which is fatal. I think we solved this with .preinit_array, but then reverted, because it does not work with dalvik apps anyway.</div>
<div><br></div><div>I think missing a pthread_create call from a library would be bad, as ASan needs to initialize some per-thread state there.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Thanks,<br>
Greg<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Sep 23, 2013 at 1:42 AM, Evgeniy Stepanov <<a href="mailto:eugenis@google.com">eugenis@google.com</a>> wrote:<br>
> For the same reason we use shared runtime on OSX.<br>
><br>
> We intercept libc calls by declaring a function with the same name in<br>
> the sanitizer runtime library. Glibc loader puts main executable early<br>
> in the symbol lookup order, which lets us interpose symbols from<br>
> shared libraries with symbols from statically linked sanitizer<br>
> runtime. Android (and AFAIK most other platforms) does not allow that,<br>
> which is why we need to LD_PRELOAD interceptors.<br>
><br>
> Static runtime will only intercept calls from the main executable, but<br>
> not from any libraries. This may work for simple standalone programs,<br>
> but you may run into puzzling failures. I would be very surprised if<br>
> it worked for any JNI code.<br>
><br>
><br>
> On Sat, Sep 21, 2013 at 9:45 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
>> +eugenis@<br>
>><br>
>><br>
>> On Sat, Sep 21, 2013 at 4:58 AM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>> wrote:<br>
>>><br>
>>> Why does compiler-rt ship a shared object for ASan on Android instead<br>
>>> of a static library?  Would statically linking ASan on Android at<br>
>>> least be safe for standalone executables?<br>
>>><br>
>>> And if I'm wanting to use ASan in C++ code that is invoked from an<br>
>>> APK, can I statically link ASan?  If not, what is the reason we need<br>
>>> to preload Dalvik with the ASan shared object?  I assume static<br>
>>> linking here would mean that ASan would miss leaks and overflows in<br>
>>> Dalvik, but are there other drawbacks?<br>
>>><br>
>>> Thanks,<br>
>>> Greg<br>
>>> _______________________________________________<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>
>><br>
>><br>
</div></div></blockquote></div><br></div></div>