[ASAN] Do not consider alignment during object size calculations #109120
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@llvm/pr-subscribers-compiler-rt-sanitizer Author: Pavel Skripkin (pskrgag) ChangesIt was found that ASAN logic optimizes away out-of-bound access instrumentation for over-aligned arrays. See #108287 for complete code examples. Fix it by not considering alignment during object size calculation, since out-of-bounds access for over-aligned object is still UB and should be reported by ASAN. Closes: #108287 Full diff: https://github.com/llvm/llvm-project/pull/109120.diff 2 Files Affected:
diff --git a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
index e8a95f5dfd435c..8f1e3e0764a7f1 100644
--- a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -3057,9 +3057,7 @@ bool AddressSanitizer::instrumentFunction(Function &F,
OperandsToInstrument.size() + IntrinToInstrument.size() >
(unsigned)InstrumentationWithCallsThreshold);
const DataLayout &DL = F.getDataLayout();
- ObjectSizeOpts ObjSizeOpts;
- ObjSizeOpts.RoundToAlign = true;
- ObjectSizeOffsetVisitor ObjSizeVis(DL, TLI, F.getContext(), ObjSizeOpts);
+ ObjectSizeOffsetVisitor ObjSizeVis(DL, TLI, F.getContext());
// Instrument.
int NumInstrumented = 0;
diff --git a/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll b/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll
index 2f26a7d9f44535..bcaf54deed21cb 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll
@@ -16,6 +16,7 @@ target triple = "x86_64-unknown-linux-gnu"
; indexed with constants in-bounds. But instrument all other cases.
@GlobSt = global [10 x i32] zeroinitializer, align 16 ; static initializer
+@GlobStAlignInBounds = global [10 x i8] zeroinitializer, align 16 ; static initializer
@GlobDy = global [10 x i32] zeroinitializer, align 16, sanitize_address_dyninit ; dynamic initializer
@GlobEx = external global [10 x i32] , align 16 ; extern initializer
@@ -49,6 +50,26 @@ entry:
; CHECK: ret i32
}
+; GlobStAlignInBount is accessed with out of bounds index, but in bounds of allocated area (because of alignemnt)
+define i8 @AccessGlobStAlignInBounds_0_11() sanitize_address {
+entry:
+ %0 = load i8, ptr getelementptr inbounds ([10 x i8], ptr @GlobStAlignInBounds, i64 0, i64 11), align 1
+ ret i8 %0
+; CHECK-LABEL: define i8 @AccessGlobStAlignInBounds_0_11
+; CHECK: __asan_report
+; CHECK: ret i8
+}
+
+; GlobStAlignInBount is accessed with in-bound index
+define i8 @AccessGlobStAlignInBounds_0_9() sanitize_address {
+entry:
+ %0 = load i8, ptr getelementptr inbounds ([10 x i8], ptr @GlobStAlignInBounds, i64 0, i64 9), align 1
+ ret i8 %0
+; CHECK-LABEL: define i8 @AccessGlobStAlignInBounds_0_9
+; CHECK-NOT: __asan_report
+; CHECK: ret i8
+}
+
; GlobDy is declared with dynamic initializer -- can't optimize.
define i32 @AccessGlobDy_0_2() sanitize_address {
entry:
|
|
@llvm/pr-subscribers-llvm-transforms Author: Pavel Skripkin (pskrgag) ChangesIt was found that ASAN logic optimizes away out-of-bound access instrumentation for over-aligned arrays. See #108287 for complete code examples. Fix it by not considering alignment during object size calculation, since out-of-bounds access for over-aligned object is still UB and should be reported by ASAN. Closes: #108287 Full diff: https://github.com/llvm/llvm-project/pull/109120.diff 2 Files Affected:
diff --git a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
index e8a95f5dfd435c..8f1e3e0764a7f1 100644
--- a/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -3057,9 +3057,7 @@ bool AddressSanitizer::instrumentFunction(Function &F,
OperandsToInstrument.size() + IntrinToInstrument.size() >
(unsigned)InstrumentationWithCallsThreshold);
const DataLayout &DL = F.getDataLayout();
- ObjectSizeOpts ObjSizeOpts;
- ObjSizeOpts.RoundToAlign = true;
- ObjectSizeOffsetVisitor ObjSizeVis(DL, TLI, F.getContext(), ObjSizeOpts);
+ ObjectSizeOffsetVisitor ObjSizeVis(DL, TLI, F.getContext());
// Instrument.
int NumInstrumented = 0;
diff --git a/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll b/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll
index 2f26a7d9f44535..bcaf54deed21cb 100644
--- a/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll
+++ b/llvm/test/Instrumentation/AddressSanitizer/instrument_global.ll
@@ -16,6 +16,7 @@ target triple = "x86_64-unknown-linux-gnu"
; indexed with constants in-bounds. But instrument all other cases.
@GlobSt = global [10 x i32] zeroinitializer, align 16 ; static initializer
+@GlobStAlignInBounds = global [10 x i8] zeroinitializer, align 16 ; static initializer
@GlobDy = global [10 x i32] zeroinitializer, align 16, sanitize_address_dyninit ; dynamic initializer
@GlobEx = external global [10 x i32] , align 16 ; extern initializer
@@ -49,6 +50,26 @@ entry:
; CHECK: ret i32
}
+; GlobStAlignInBount is accessed with out of bounds index, but in bounds of allocated area (because of alignemnt)
+define i8 @AccessGlobStAlignInBounds_0_11() sanitize_address {
+entry:
+ %0 = load i8, ptr getelementptr inbounds ([10 x i8], ptr @GlobStAlignInBounds, i64 0, i64 11), align 1
+ ret i8 %0
+; CHECK-LABEL: define i8 @AccessGlobStAlignInBounds_0_11
+; CHECK: __asan_report
+; CHECK: ret i8
+}
+
+; GlobStAlignInBount is accessed with in-bound index
+define i8 @AccessGlobStAlignInBounds_0_9() sanitize_address {
+entry:
+ %0 = load i8, ptr getelementptr inbounds ([10 x i8], ptr @GlobStAlignInBounds, i64 0, i64 9), align 1
+ ret i8 %0
+; CHECK-LABEL: define i8 @AccessGlobStAlignInBounds_0_9
+; CHECK-NOT: __asan_report
+; CHECK: ret i8
+}
+
; GlobDy is declared with dynamic initializer -- can't optimize.
define i32 @AccessGlobDy_0_2() sanitize_address {
entry:
|
|
smth weird failed on CI seems unrelated? |
vitalybuka
approved these changes
Sep 19, 2024
|
Thanks for the report and fix! |
tmsri
pushed a commit
to tmsri/llvm-project
that referenced
this pull request
Sep 19, 2024
…m#109120) It was found that ASAN logic optimizes away out-of-bound access instrumentation for over-aligned arrays. See llvm#108287 for complete code examples. Fix it by not considering alignment during object size calculation, since out-of-bounds access for over-aligned object is still UB and should be reported by ASAN. Closes: llvm#108287
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It was found that ASAN logic optimizes away out-of-bound access instrumentation for over-aligned arrays. See #108287 for complete code examples.
Fix it by not considering alignment during object size calculation, since out-of-bounds access for over-aligned object is still UB and should be reported by ASAN.
Closes: #108287