This function initializes enough of the runtime to be able to run
instrumented code in a statically linked executable. It replaces
__hwasan_shadow_init() which wasn't doing enough initialization for
instrumented code that uses either TLS or IFUNC to work.
Details
Diff Detail
- Repository
- rCRT Compiler Runtime
Event Timeline
compiler-rt/include/sanitizer/hwasan_interface.h | ||
---|---|---|
26 ↗ | (On Diff #184411) | It should fine to call this function in dynamic executables if __rela_iplt symbols are declared weak. In that case, would it be possible to get rid of hwasan_init_static, and simply call hwasan_init early enough? If not, is there a corresponding bionic patch to use__hwasan_init_static? |
compiler-rt/include/sanitizer/hwasan_interface.h | ||
---|---|---|
26 ↗ | (On Diff #184411) |
They don't even need to be declared weak, the symbols point to the IRELATIVEs in dynamic executables as well. In PIEs and DSOs I guess it's possible (though extremely unlikely) for the r_offset for an unrelated ifunc to match the address of __hwasan_shadow, which would end up calling the wrong resolver (and segfaulting if RELRO was applied). And this will definitely segfault if the executable is a dynamically linked non-PIE (which isn't supported on Android but could be on other platforms).
I think that won't work because the call to madvise in MadviseShadow requires libc to be initialized more than it is currently at the point where __hwasan_init is currently called in bionic (which AFAICT was the motivation for adding __hwasan_init_shadow in D50581).
It's basically just s/__hwasan_init/__hwasan_init_static/g in bionic. I'll send it out in a bit. |
LGTM
Doing less things while libc is not fully initialized is a step in the right direction.
compiler-rt/include/sanitizer/hwasan_interface.h | ||
---|---|---|
26 ↗ | (On Diff #184411) |
Hmm, actually it's only lld which has this behaviour. I'll make them weak. |
compiler-rt/include/sanitizer/hwasan_interface.h | ||
---|---|---|
26 ↗ | (On Diff #184411) | r352823 |