This is an archive of the discontinued LLVM Phabricator instance.

[sanitizers] Invalidate GlobalsAA
ClosedPublic

Authored by vitalybuka on Sep 6 2022, 7:23 PM.

Details

Summary

GlobalsAA is considered stateless as usually transformations do not introduce
new global accesses, and removed global access is not a problem for GlobalsAA
users.
Sanitizers introduce new global accesses:

  • Msan and Dfsan tracks origins and parameters with TLS, and to store stack origins.
    • Sancov uses global counters. HWAsan store tag state in TLS.
    • Asan modifies globals, but I am not sure if invalidation is required.

I see no evidence that TSan needs invalidation.

Diff Detail

Event Timeline

vitalybuka created this revision.Sep 6 2022, 7:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 6 2022, 7:23 PM
vitalybuka requested review of this revision.Sep 6 2022, 7:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 6 2022, 7:23 PM

Mentioning in the summary that GlobalsAA only expects simplification and therefore doesn't expect new globals (as I understand). Also that GlobalsAA is special in the way it's invalidated/updated.
I'd like somebody like @asbirlea to confirm this.

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

adding comments here would be helpful

asbirlea added a comment.EditedSep 8 2022, 9:30 AM

Confirming this is necessary - the patch came after an offline discussion of the issue.
+1 to adding comments to explain why this is needed: GlobalsAA is considered stateless and does not get invalidated unless explicitly invalidated; PreservedAnalyses::none() is not enough. Sanitizers make changes that require GlobalsAA to be invalidated.

also it would be nice to have some sort of check to detect this sort of issue with GlobalsAA and instrumentation passes, perhaps gated under expensive checks. haven't thought too hard on how that would work

vitalybuka edited the summary of this revision. (Show Details)Sep 8 2022, 11:24 AM

also it would be nice to have some sort of check to detect this sort of issue with GlobalsAA and instrumentation passes, perhaps gated under expensive checks. haven't thought too hard on how that would work

I assume not in this patch?

aeubanks accepted this revision.Sep 8 2022, 11:35 AM

also it would be nice to have some sort of check to detect this sort of issue with GlobalsAA and instrumentation passes, perhaps gated under expensive checks. haven't thought too hard on how that would work

I assume not in this patch?

yeah not here, I'm just randomly throwing out ideas

llvm/test/Instrumentation/MemorySanitizer/msan_invalidate.ll
8

if possible could you reduce this test case? e.g. dso_local/target datalayout/triple/lifetime/noundef

This revision is now accepted and ready to land.Sep 8 2022, 11:35 AM
vitalybuka updated this revision to Diff 458840.Sep 8 2022, 1:18 PM

simplify tests

vitalybuka marked an inline comment as done.Sep 8 2022, 1:18 PM
vitalybuka marked an inline comment as done.
This revision was landed with ongoing or failed builds.Sep 8 2022, 2:01 PM
This revision was automatically updated to reflect the committed changes.