[LLVMdev] [ASan] static linking on android?

[Greg Fitzgerald]

> Static runtime will only intercept calls from the main executable, but
> not from any libraries. This may work for simple standalone programs,
> but you may run into puzzling failures.

What type of failures do you mean?  Does the symbol mismatch break
assumptions in the ASan runtime?  It's easy to imagine, for example,
ASan missing use-after-free bugs because the call to free() is in an
uninstrumented shared library.  But would you expect
stack-buffer-overflow and heap-buffer-overflow detection to work as
expected?

Thanks,
Greg


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