Skip to content
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

[hwasan] Fix rare false negative (zero tag) in two more test cases #69491

Merged
merged 1 commit into from
Oct 19, 2023

Conversation

thurstond
Copy link
Contributor

stack-uas.c and stack-history-length.c both have
-hwasan-record-stack-history=libcall, which makes the stack base
tag fully randomized. They may therefore sometimes have a zero tag
for a stack allocated variable, resulting in a false negative
(#69221 (comment)).

This patch applies the same workaround as used for deep-recursion.c
(aa4dfd3)
and stack-uar.c
(ddf1de2):
have two adjacent stack-allocated variables, and use whichever is not
zero-tagged.

These are the last remaining test cases that use -hwasan-record-stack-history=libcall.

stack-uas flakiness spotted in the wild: https://lab.llvm.org/buildbot/#/builders/269/builds/549/steps/11/logs/stdio
stack-history-length: https://lab.llvm.org/buildbot/#/builders/269/builds/537

stack-uas.c and stack-history-length.c both have
-hwasan-record-stack-history=libcall, which makes the stack base
tag fully randomized. They may therefore sometimes have a zero tag
for a stack allocated variable, resulting in a false negative
(llvm#69221 (comment)).

This patch applies the same workaround as used for deep-recursion.c
(llvm@aa4dfd3)
and stack-uar.c
(llvm@ddf1de2):
have two adjacent stack-allocated variables, and use whichever is not
zero-tagged.

These are the last remaining test cases that use -hwasan-record-stack-history=libcall.

stack-uas flakiness spotted in the wild: https://lab.llvm.org/buildbot/#/builders/269/builds/549/steps/11/logs/stdio
stack-history-length: https://lab.llvm.org/buildbot/#/builders/269/builds/537
@llvmbot
Copy link
Member

llvmbot commented Oct 18, 2023

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Thurston Dang (thurstond)

Changes

stack-uas.c and stack-history-length.c both have
-hwasan-record-stack-history=libcall, which makes the stack base
tag fully randomized. They may therefore sometimes have a zero tag
for a stack allocated variable, resulting in a false negative
(#69221 (comment)).

This patch applies the same workaround as used for deep-recursion.c
(aa4dfd3)
and stack-uar.c
(ddf1de2):
have two adjacent stack-allocated variables, and use whichever is not
zero-tagged.

These are the last remaining test cases that use -hwasan-record-stack-history=libcall.

stack-uas flakiness spotted in the wild: https://lab.llvm.org/buildbot/#/builders/269/builds/549/steps/11/logs/stdio
stack-history-length: https://lab.llvm.org/buildbot/#/builders/269/builds/537


Full diff: https://github.com/llvm/llvm-project/pull/69491.diff

2 Files Affected:

  • (modified) compiler-rt/test/hwasan/TestCases/stack-history-length.c (+20-1)
  • (modified) compiler-rt/test/hwasan/TestCases/stack-uas.c (+19-3)
diff --git a/compiler-rt/test/hwasan/TestCases/stack-history-length.c b/compiler-rt/test/hwasan/TestCases/stack-history-length.c
index d997677b4e90b8c..6b1274892c07485 100644
--- a/compiler-rt/test/hwasan/TestCases/stack-history-length.c
+++ b/compiler-rt/test/hwasan/TestCases/stack-history-length.c
@@ -11,6 +11,8 @@
 // Stack histories are currently not recorded on x86.
 // XFAIL: target=x86_64{{.*}}
 
+#include <assert.h>
+#include <sanitizer/hwasan_interface.h>
 #include <stdlib.h>
 
 void USE(void *x) { // pretend_to_do_something(void *x)
@@ -20,7 +22,24 @@ void USE(void *x) { // pretend_to_do_something(void *x)
 volatile int four = 4;
 __attribute__((noinline)) void FUNC0() { int x[4]; USE(&x[0]); }
 __attribute__((noinline)) void FUNC() { int x[4]; USE(&x[0]); }
-__attribute__((noinline)) void OOB() { int x[4]; x[four] = 0; USE(&x[0]); }
+__attribute__((noinline)) void OOB() {
+  int x[4];
+  int y[4];
+  // With -hwasan-generate-tags-with-calls=false, stack tags can occasionally
+  // be zero, leading to a false negative
+  // (https://github.com/llvm/llvm-project/issues/69221). Work around it by
+  // using the neighboring variable, which is guaranteed by
+  // -hwasan-generate-tags-with-calls=false to have a different (hence
+  // non-zero) tag.
+  if (__hwasan_tag_pointer(x, 0) == x) {
+    assert(__hwasan_tag_pointer(y, 0) != y);
+    y[four] = 0;
+  } else {
+    x[four] = 0;
+  }
+  USE(&x[0]);
+  USE(&y[0]);
+}
 
 int main(int argc, char **argv) {
   int X = argc == 2 ? atoi(argv[1]) : 10;
diff --git a/compiler-rt/test/hwasan/TestCases/stack-uas.c b/compiler-rt/test/hwasan/TestCases/stack-uas.c
index 53d51ee25dca32e..4455e5910074750 100644
--- a/compiler-rt/test/hwasan/TestCases/stack-uas.c
+++ b/compiler-rt/test/hwasan/TestCases/stack-uas.c
@@ -13,6 +13,10 @@
 // Stack histories currently are not recorded on x86.
 // XFAIL: target=x86_64{{.*}}
 
+#include <assert.h>
+#include <sanitizer/hwasan_interface.h>
+#include <stdio.h>
+
 void USE(void *x) { // pretend_to_do_something(void *x)
   __asm__ __volatile__(""
                        :
@@ -36,8 +40,20 @@ __attribute__((noinline)) void Unrelated3() {
 __attribute__((noinline)) char buggy() {
   char *volatile p;
   {
-    char zzz[0x1000] = {};
-    p = zzz;
+    char zzz[0x800] = {};
+    char yyy[0x800] = {};
+    // With -hwasan-generate-tags-with-calls=false, stack tags can occasionally
+    // be zero, leading to a false negative
+    // (https://github.com/llvm/llvm-project/issues/69221). Work around it by
+    // using the neighboring variable, which is guaranteed by
+    // -hwasan-generate-tags-with-calls=false to have a different (hence
+    // non-zero) tag.
+    if (__hwasan_tag_pointer(zzz, 0) == zzz) {
+      assert(__hwasan_tag_pointer(yyy, 0) != yyy);
+      p = yyy;
+    } else {
+      p = zzz;
+    }
   }
   return *p;
 }
@@ -53,7 +69,7 @@ int main() {
   // CHECK: Cause: stack tag-mismatch
   // CHECK: is located in stack of thread
   // CHECK: Potentially referenced stack objects:
-  // CHECK-NEXT: zzz in buggy {{.*}}stack-uas.c:[[@LINE-17]]
+  // CHECK-NEXT: {{zzz|yyy}} in buggy {{.*}}stack-uas.c:
   // CHECK-NEXT: Memory tags around the buggy address
 
   // NOSYM: Previously allocated frames:

Copy link
Collaborator

@DavidSpickett DavidSpickett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants