[PATCH] D100967: [dfsan] Track origin at loads

[stephan.yichao.zhao via Phabricator via llvm-commits]

stephan.yichao.zhao created this revision.
stephan.yichao.zhao added a reviewer: gbalats.
Herald added a subscriber: hiraditya.
stephan.yichao.zhao requested review of this revision.
Herald added projects: Sanitizers, LLVM.
Herald added subscribers: llvm-commits, Sanitizers.

  The first version of origin tracking tracks only memory stores. Although
  this is sufficient for understanding correct flows, it is hard to figure
  out where an undefined value is read from. To find reading undefined values,
  we still have to do a reverse binary search from the last store in the chain
  with printing and logging at possible code paths. This is
  quite inefficient.
  
  Tracking memory load instructions can help this case. The main issues of
  tracking loads are performance and code size overheads.
  
  With tracking only stores, the code size overhead is 38%,
  memory overhead is 1x, and cpu overhead is 3x. In practice #load is much
  larger than #store, so both code size and cpu overhead increases. The
  first blocker is code size overhead: link fails if we inline tracking
  loads. The workaround is using external function calls to propagate
  metadata. This is also the workaround ASan uses. The cpu overhead
  is ~10x. This is a trade off between debuggability and performance.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100967

Files:
  compiler-rt/lib/dfsan/dfsan.cpp
  compiler-rt/test/dfsan/origin_track_ld.c
  llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
  llvm/test/Instrumentation/DataFlowSanitizer/basic.ll
  llvm/test/Instrumentation/DataFlowSanitizer/origin_track_load.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D100967.339099.patch
Type: text/x-patch
Size: 13715 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210421/53ee3b15/attachment.bin>