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 > >
> 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 >> >>
On Tue, Sep 24, 2013 at 10:32 PM, Greg Fitzgerald <garious at gmail.com> wrote:> > 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? >Malloc/free are special on Android - they are intercepted with bionic debug malloc hooks, which work fine with statically linked runtime. 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. I think missing a pthread_create call from a library would be bad, as ASan needs to initialize some per-thread state there.> > 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 > >> > >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130924/c8f45675/attachment.html>