[PATCH] D56672: [HWASAN] Instrument globals

[Eugene Leviant via Phabricator via llvm-commits]

evgeny777 updated this revision to Diff 196456.
evgeny777 added a comment.
Herald added subscribers: javed.absar, mgorny.

Ok, I finally have some time to work on this again
**Changes**

- External globals are instrumented via alias creation (suggested by @pcc). Compiler forces access to them via GOT even if they're dso_local
- Internal globals are instrumented by means of GEP pointer tagging (same as before)
- Interposable globals are not instrumented, but marked with special attribute, so they're accessed via GOT
- Hidden globals are not instrumented. They can't be accessed via GOT, because this will make such variables preemptive and not making them preemptive causes relocation overflow at link time

**Testing**

To test the patch(es) I used RPI3 board with slightly modified Linux kernel (`__user` pointer untagging in syscalls). I ran two different test suites

- LLVM/clang compiled with `-DLLVM_BUILD_LLVM_DYLIB=ON` and  `-DLLVM_LINK_LLVM_DYLIB=ON`. Toolchain was deployed on board and lit tests were run. Looks good so far

- LLVM test suite tests. Those triggered a number of TAG mismatch errors, one of them in `hbd.test`:

  // decomp.cpp:
  Exp *stack[8];
  Exp **stkptr;
  // .....
  int decompileblock(Classfile *c, method_info_ptr mi) {
    // ...
    stkptr = stack;
    // ... pushunop is called later in this function ...
  }

  // d6-arith.cpp
  int pushunop(Classfile *c) /* push unary operation, popping operand e.g. lneg */
  {
    Exp *e1 = *(stkptr-1);
    // ....
  }

There are quite a few other read overflows, for example in `lencod` and `ldecod`. I haven't investigated them thoroughly, but may be this would make sense if decide to proceed with this patch.

**Issues**

- Linking with ld.bfd requires `-Wl,--no-relax`. I haven't investigated this yet (ld.lld works fine).
- Linking uninstrumented code with weak or common symbols with instrumented code containing strong versions of those symbols will not work. This probably can be fixed at least for AArch64 by means of untagging symbol addresses on the linker side.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56672/new/

https://reviews.llvm.org/D56672

Files:
  cmake/modules/HandleLLVMOptions.cmake
  include/llvm/InitializePasses.h
  include/llvm/Transforms/Instrumentation.h
  lib/Target/TargetMachine.cpp
  lib/Transforms/Instrumentation/AddressSanitizer.cpp
  lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  lib/Transforms/Instrumentation/Instrumentation.cpp
  test/Instrumentation/HWAddressSanitizer/globals-aarch64.ll
  test/Instrumentation/HWAddressSanitizer/globals.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D56672.196456.patch
Type: text/x-patch
Size: 25799 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190424/9686b91b/attachment.bin>