This is an archive of the discontinued LLVM Phabricator instance.

[dfsan] Add a flag about whether to propagate offset labels at gep
ClosedPublic

Authored by stephan.yichao.zhao on May 26 2021, 8:57 AM.

Details

Summary

DFSan has flags to control flows between pointers and objects referred
by pointers. For example,

a = *p;
L(a) = L(*p)        when -dfsan-combine-pointer-labels-on-load = false
L(a) = L(*p) + L(p) when -dfsan-combine-pointer-labels-on-load = true

*p = b;
L(*p) = L(b)        when -dfsan-combine-pointer-labels-on-store = false
L(*p) = L(b) + L(p) when -dfsan-combine-pointer-labels-on-store = true

The question is what to do with p += c.

In practice we found many confusing flows if we propagate labels from c
to p. So a new flag works like this

p += c;
L(p) = L(p)        when -dfsan-propagate-via-pointer-arithmetic = false
L(p) = L(p) + L(c) when -dfsan-propagate-via-pointer-arithmetic = true

Diff Detail

Event Timeline

stephan.yichao.zhao requested review of this revision.May 26 2021, 8:57 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 26 2021, 8:57 AM
Herald added subscribers: llvm-commits, Restricted Project. · View Herald Transcript
gbalats added inline comments.May 26 2021, 3:16 PM
compiler-rt/test/dfsan/gep.c
16

Why is this needed?

llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
204

Why do we need the negated condition and not have CombinePointerLabelsOnLoad instead? Same for other options.
We should be able to set a default value that doesn't have to be the 0 bitmask.

210

Out of curiosity, is there any benefit other in logically grouping these together when using cl::bits vs having individual options?

stephan.yichao.zhao marked an inline comment as done.
stephan.yichao.zhao retitled this revision from [dfsan] Add a flag about whether to propagate offset labels at gep to [dfsan] Add a flag about whether to propagate offset labels at gep.

switched back from option set to individual options.

compiler-rt/test/dfsan/gep.c
16

removed.

llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
204

This is because options set do not support default values. I changed back to using individual options.

210

A set of options mainly make the code more readable.
But it does not have a way to set default values. so I switched back to use individual options. To make them readable, we may add an argument group later.

gbalats added inline comments.May 27 2021, 3:10 PM
compiler-rt/test/dfsan/gep.c
16
16

Can you add another case where p is not a pointer but is incremented in the same way to demonstrate that propagation always happens for non-pointers?

17

You could remove the need for macros by just printing the result of dfsan_get_label and using different CHECK prefixes for the two run invocations above.

llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
2794–2796

Use getPointerOperand instead and extract to variable.

llvm/test/Instrumentation/DataFlowSanitizer/dont_combine_offset_labels_on_gep.ll
3
14

nit: For PO and PS which are numeric, I find it easier to use %[[#PO:]] and then reference it by %[[#PO]]

17
stephan.yichao.zhao marked 6 inline comments as done.

update

compiler-rt/test/dfsan/gep.c
17

Most other cases use assert to check labels. So this is consistent with others.

llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
2794–2796

Thank you.

gbalats accepted this revision.May 27 2021, 4:54 PM
This revision is now accepted and ready to land.May 27 2021, 4:54 PM
This revision was landed with ongoing or failed builds.May 27 2021, 5:08 PM
This revision was automatically updated to reflect the committed changes.