[ASan] static linking on android?

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

+eugenis@

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.

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

> 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.