[PATCH] D109816: [hwasan] also omit safe mem[cpy|mov|set].
Florian Mayer via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 16 05:05:35 PDT 2021
fmayer added inline comments.
================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:789
return true;
- } else if (SSI && SSI->accessIsSafe(*Inst)) {
+ } else if (SSI && SSI->accessIsSafe(*Inst) && findAllocaForValue(Ptr)) {
return true;
----------------
eugenis wrote:
> Is this a separate bugfix?
>
> Am I right that this is not needed for regular load/store because the argument is required to be 100% traceable to a single alloca, but 2-args memintrinsics are safe if one arg is 100%, and the other is 100% not stack? That does not sound right.
>
> The comment on accessIsSafe does not even try to cover such cases. Also, I do not see any tests under Analysis/StackSafety for the mixed memintrinsic case.
Before this change, we only checked this for instructions that took a single pointer variable. There were two cases in `accessIsSafe`:
* the pointer is non stack: we never reached this instruction in the stack safety pass, and we return false because we do not find it in the mapping.
* the pointer is potentially stack: we reach this instruction in the pass, and SECV will take care of checking whether we can *only* reach it from the alloca.
Now, for memcpy / memmove there is the extra case that we can have both cases for two arguments. Now the problem becomes if one argument is in range of the alloca, but the other one isn't reachable from any alloca, accessIsSafe will return true.
What I did in this change is clarify the semantics (as they already were) of accessIsSafe in the comment, and defer responsibility to check whether *all* arguments are potentially stack to the caller. As such, we only hit the second case above.
================
Comment at: llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll:132
+ %y = bitcast [10 x i8]* %buf.sroa.1 to i8*
+ call void @llvm.lifetime.start.p0i8(i64 10, i8* nonnull %x)
+ call void @llvm.lifetime.start.p0i8(i64 10, i8* nonnull %y)
----------------
eugenis wrote:
> If lifetimes are irrelevant to a test case, you can just remove them altogether.
>
The stack safety does look at lifetimes, so to make it more representative I put them there. Either way is fine, WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109816/new/
https://reviews.llvm.org/D109816
More information about the llvm-commits
mailing list