Skip to content

[NFC] [HWASan] pull removeFnAttributes into function #109488

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 43 additions & 34 deletions llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -316,6 +316,7 @@ class HWAddressSanitizer {
FunctionAnalysisManager &FAM) const;
void initializeModule();
void createHwasanCtorComdat();
void removeFnAttributes(Function *F);

void initializeCallbacks(Module &M);

Expand Down Expand Up @@ -591,47 +592,55 @@ void HWAddressSanitizer::createHwasanCtorComdat() {
appendToCompilerUsed(M, Dummy);
}

void HWAddressSanitizer::removeFnAttributes(Function *F) {
// Remove memory attributes that are invalid with HWASan.
// HWASan checks read from shadow, which invalidates memory(argmem: *)
// Short granule checks on function arguments read from the argument memory
// (last byte of the granule), which invalidates writeonly.
//
// This is not only true for sanitized functions, because AttrInfer can
// infer those attributes on libc functions, which is not true if those
// are instrumented (Android) or intercepted.
//
// We might want to model HWASan shadow memory more opaquely to get rid of
// this problem altogether, by hiding the shadow memory write in an
// intrinsic, essentially like in the AArch64StackTagging pass. But that's
// for another day.

// The API is weird. `onlyReadsMemory` actually means "does not write", and
// `onlyWritesMemory` actually means "does not read". So we reconstruct
// "accesses memory" && "does not read" <=> "writes".
bool Changed = false;
if (!F->doesNotAccessMemory()) {
bool WritesMemory = !F->onlyReadsMemory();
bool ReadsMemory = !F->onlyWritesMemory();
if ((WritesMemory && !ReadsMemory) || F->onlyAccessesArgMemory()) {
F->removeFnAttr(Attribute::Memory);
Changed = true;
}
}
for (Argument &A : F->args()) {
if (A.hasAttribute(Attribute::WriteOnly)) {
A.removeAttr(Attribute::WriteOnly);
Changed = true;
}
}
if (Changed) {
// nobuiltin makes sure later passes don't restore assumptions about
// the function.
F->addFnAttr(Attribute::NoBuiltin);
}
}

/// Module-level initialization.
///
/// inserts a call to __hwasan_init to the module's constructor list.
void HWAddressSanitizer::initializeModule() {
LLVM_DEBUG(dbgs() << "Init " << M.getName() << "\n");
TargetTriple = Triple(M.getTargetTriple());

for (auto &F : M.functions()) {
// Remove memory attributes that are invalid with HWASan.
// HWASan checks read from shadow, which invalidates memory(argmem: *)
// Short granule checks on function arguments read from the argument memory
// (last byte of the granule), which invalidates writeonly.
//
// This is not only true for sanitized functions, because AttrInfer can
// infer those attributes on libc functions, which is not true if those
// are instrumented (Android) or intercepted.

// The API is weird. `onlyReadsMemory` actually means "does not write", and
// `onlyWritesMemory` actually means "does not read". So we reconstruct
// "accesses memory" && "does not read" <=> "writes".
bool Changed = false;
if (!F.doesNotAccessMemory()) {
bool WritesMemory = !F.onlyReadsMemory();
bool ReadsMemory = !F.onlyWritesMemory();
if ((WritesMemory && !ReadsMemory) || F.onlyAccessesArgMemory()) {
F.removeFnAttr(Attribute::Memory);
Changed = true;
}
}
for (Argument &A : F.args()) {
if (A.hasAttribute(Attribute::WriteOnly)) {
Changed = true;
A.removeAttr(Attribute::WriteOnly);
}
}
if (Changed) {
// nobuiltin makes sure later passes don't restore assumptions about
// the function.
F.addFnAttr(Attribute::NoBuiltin);
}
}
for (Function &F : M.functions())
removeFnAttributes(&F);

// x86_64 currently has two modes:
// - Intel LAM (default)
Expand Down
Loading