[PATCH] D97310: [dfsan] Conservative solution to atomic load/store

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

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

DFSan at store does store shadow data; store app data; and at load does
 load shadow data; load app data.

When an application data is atomic, one overtainting case is

  thread A: load shadow
  thread B: store shadow
  thread B: store app
  thread A: load app

If the application address had been used by other flows, thread A reads
previous shadow, causing overtainting.

The change is similar to MSan's solution.

1. enforce ordering of app load/store
2. load shadow after load app; store shadow before shadow app
3. do not track atomic store by reseting its shadow to be 0.

The last one is to address a case like this.

  Thread A: load app
  Thread B: store shadow
  Thread A: load shadow
  Thread B: store app

This approach eliminates overtainting as a trade-off between undertainting
flows via shadow data race.

Note that this change addresses only native atomic instructions, but
does not support builtin atomic libcalls <https://llvm.org/docs/Atomics.html#libcalls-atomic> yet.

         


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D97310

Files:
  compiler-rt/test/dfsan/atomic.cpp
  llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
  llvm/test/Instrumentation/DataFlowSanitizer/atomics.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D97310.325846.patch
Type: text/x-patch
Size: 24689 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210223/a9e29128/attachment.bin>