[PATCH] D101584: [dfsan] Fix origin tracking for fast8

[George Balatsouras via Phabricator via llvm-commits]

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

The problem is the following. With fast8, we broke an important invariant when loading shadows.
A wide shadow of 64 bits used to correspond to 4 application bytes with fast16; so, generating a single load was okay since those 4 application bytes would share a single origin.
Now, using fast8, a wide shadow of 64 bits corresponds to 8 application bytes that should be backed by 2 origins (but we kept generating just one).

Let’s say our wide shadow is 64-bit and consists of the following: 0xABCDEFGH. To check if we need the second origin value, we could do the following (on the 64-bit wide shadow) case:

- bitwise shift the wide shadow left by 32 bits (yielding 0xEFGH0000)
- push the result along with the first origin load to the shadow/origin vectors
- load the second 32-bit origin of the 64-bit wide shadow
- push the wide shadow along with the second origin to the shadow/origin vectors.

The combineOrigins would then select the second origin if the wide shadow is of the form 0xABCDE0000.
The tests illustrate how this change affects the generated bitcode.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101584

Files:
  llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
  llvm/test/Instrumentation/DataFlowSanitizer/origin_load.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D101584.341689.patch
Type: text/x-patch
Size: 9853 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210429/99da105c/attachment.bin>