This is an archive of the discontinued LLVM Phabricator instance.

hwasan: Use system allocator to realloc and free untagged pointers in interceptor mode.
ClosedPublic

Authored by pcc on Dec 21 2018, 12:02 AM.

Details

Summary

The Android dynamic loader has a non-standard feature that allows
libraries such as the hwasan runtime to interpose symbols even after
the symbol already has a value. The new value of the symbol is used to
relocate libraries loaded after the interposing library, but existing
libraries keep the old value.

What this means in practice is that if we have .so files that depend
on interceptor-mode hwasan without the main executable depending on
it, some of the libraries in the process will be using the hwasan
allocator and some will be using the system allocator, and these
allocators need to interact somehow. For example, if an instrumented
library calls a function such as strdup that allocates memory on
behalf of the caller, the instrumented library can reasonably expect
to be able to call free to deallocate the memory.

We can handle that relatively easily with hwasan by using tag 0 to
represent allocations from the system allocator. If hwasan's realloc
or free functions are passed a pointer with tag 0, the system allocator
is called.

One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Dec 21 2018, 12:02 AM
eugenis accepted this revision.Dec 27 2018, 2:53 PM

LGTM

Mention that this loader feature is enabled by DF_GLOBAL somewhere in the patch description.

One limitation is that this scheme doesn't work in reverse: if an
instrumented library allocates memory, it must free the memory itself
and cannot pass ownership to a system library. In a future change,
we may want to expose an API for calling the system allocator so
that instrumented libraries can safely transfer ownership of memory
to system libraries.

That's unfortunate, but there is not a lot we can do about it. Hopefully, it is not very common in practice.

This revision is now accepted and ready to land.Dec 27 2018, 2:53 PM
This revision was automatically updated to reflect the committed changes.