This is an archive of the discontinued LLVM Phabricator instance.

Port msan to Android (revised)
Needs ReviewPublic

Authored by thurston on Aug 10 2016, 1:21 PM.

Details

Reviewers
eugenis
Summary

This is the Msan portion of D22549, modified per the comments (and subsequent comments on this revision).

Variables that were formerly __thread will use GetMsanTLS() on Android. On non-Android, the variables are unchanged.

This requires new, corresponding changes to MemorySanitizer.cpp, to be updated shortly in D22550.

Diff Detail

Event Timeline

thurston updated this revision to Diff 67583.Aug 10 2016, 1:21 PM
thurston retitled this revision from to Port msan to Android (revised).
thurston updated this object.
thurston added a reviewer: eugenis.
thurston added a project: Restricted Project.
eugenis edited edge metadata.Aug 10 2016, 2:12 PM

Sorry, I think I've mislead you earlier. We need to keep the ABI on existing platforms, so msan_param_tls and friends (everything that's accessed from the instrumented code) must stay. Define wrappers for each of those, like
#if SANITIZE_ANDROID
#define TLSVAR(x) GetMsanTLS()->x
#else
#define TLSVAR(x) x
#endif
u64 *msan_param_tls() { return &TLSVAR(
msan_param_tls); }

msan/msan.h
31

Is this because our cmake does not link ubsan runtime? Btw, don't you need to update cmake so that "msan" target exists on android?

msan/msan_flags.inc
36

why?

msan/msan_poisoning.cc
126 ↗(On Diff #67583)

why is this necessary?

msan/msan_thread.cc
12

__msan_tls

sanitizer_common/sanitizer_linux.cc
791 ↗(On Diff #67583)

This is already done, please rebase on ToT.

thurston added inline comments.Aug 10 2016, 8:36 PM
msan/msan.h
31

I've been building msan within the Android source tree (explicitly specifying libmsan as a static library when compiling applications), which is why I haven't used ubsan (it's not set up to be linked into msan) and the compiler doesn't need to know the msan target.

msan/msan_flags.inc
36

On Android, there's some use-of-uninitialized-values early on before main() has even been reached e.g.,

`Uninitialized bytes in __interceptor_strlen at offset 44 inside [0x007f0d701f80, 45)

WARNING: MemorySanitizer: use-of-uninitialized-value 0x2a8ef: read_spec_entries(char*, int, ...) at bionic/libc/bionic/system_properties.cpp:903:11 0x29ab7: initialize_properties() at bionic/libc/bionic/system_properties.cpp:957:21 0x29877: system_properties_init at bionic/libc/bionic/system_properties.cpp:1017:14 0x1a8e3: libc_preinit() at bionic/libc/bionic/libc_init_dynamic.cpp:78:3`

I think they're innocuous, so I don't want to halt.

msan/msan_poisoning.cc
126 ↗(On Diff #67583)

Leftover code from debugging. I'll remove it.

msan/msan_thread.cc
12

This variable will be gone in the next revision (since THREADLOCAL is only applicable for non-Android, and non-Android will use the original variables rather than MsanTLSSlot).

sanitizer_common/sanitizer_linux.cc
791 ↗(On Diff #67583)

Ok

thurston updated this revision to Diff 67648.Aug 10 2016, 8:44 PM
thurston updated this object.
thurston edited edge metadata.

For non-Android, this keeps the ABI the same (uses the original variables).
For Android, this uses TLS_SLOT_TSAN.

eugenis added inline comments.Aug 11 2016, 3:08 PM
msan/msan.h
31

This code must be testable upstream, so some cmake support is necessary.

You can check how we build asan for android here: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/25050/steps/build%20compiler-rt%20android%2Fx86/logs/stdio

msan/msan_flags.inc
36

That's because libc is not instrumented, but some of its internal calls are intercepted.
It's not good to leave it like this, because it requires -msan-keep-going, which adds code size and runtime overhead. It also makes every program fail (i.e. exit with non-zero code) under MSan which is problematic for testing.

Some ideas how to handle this.

  1. Checks are disabled in nested interceptors, so intercepting anything on this stack trace would prevent this from firing.
  1. We may disable all interceptor checks before libc is initialized. Not clear how to detect this, but the idea is that after some point all that libc does it handle requests from the application, and those usually go through intercepted entrypoints, see item 1.
thurston updated this revision to Diff 67805.Aug 12 2016, 1:12 AM

Minor housekeeping: same as the sanitizer_common changes for lsan (GetTls() on 32-bit Android; and sig_setmask)