[all-commits] [llvm/llvm-project] c88fed: [dfsan] Conservative solution to atomic load/store

[Z via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c88fedef2a5d3f4c69cc668984bb93c8889890c2
      https://github.com/llvm/llvm-project/commit/c88fedef2a5d3f4c69cc668984bb93c8889890c2
  Author: Jianzhou Zhao <jianzhouzh at google.com>
  Date:   2021-02-25 (Thu, 25 Feb 2021)

  Changed paths:
    A compiler-rt/test/dfsan/atomic.cpp
    M llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
    A llvm/test/Instrumentation/DataFlowSanitizer/atomics.ll

  Log Message:
  -----------
  [dfsan] Conservative solution to atomic load/store

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 libcalls yet.
   https://llvm.org/docs/Atomics.html#libcalls-atomic

Reviewed-by: morehouse

Differential Revision: https://reviews.llvm.org/D97310