[hwasan] Add fixed_shadow_base flag

[thurstond]

When set to non-zero, the HWASan runtime will map the shadow base at the
specified constant address.

This is particularly useful in conjunction with the existing compiler option
'hwasan-mapping-offset', which bakes a hardcoded constant address into
the instrumentation.

[llvmbot]

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

Author: Thurston Dang (thurstond)

Changes

When set to non-zero, the HWASan runtime will map the shadow base at the
specified constant address.

This is particularly useful in conjunction with the existing compiler option
'hwasan-mapping-offset', which bakes a hardcoded constant address into
the instrumentation.

---

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

2 Files Affected:

• (modified) compiler-rt/lib/hwasan/hwasan_flags.inc (+7)
• (modified) compiler-rt/lib/hwasan/hwasan_linux.cpp (+8-2)

diff --git a/compiler-rt/lib/hwasan/hwasan_flags.inc b/compiler-rt/lib/hwasan/hwasan_flags.inc
index 978fa46b705cb9e..bb224fbb8eaa8b9 100644
--- a/compiler-rt/lib/hwasan/hwasan_flags.inc
+++ b/compiler-rt/lib/hwasan/hwasan_flags.inc
@@ -84,3 +84,10 @@ HWASAN_FLAG(bool, malloc_bisect_dump, false,
 // are untagged before the call.
 HWASAN_FLAG(bool, fail_without_syscall_abi, true,
             "Exit if fail to request relaxed syscall ABI.")
+
+HWASAN_FLAG(
+    uptr, fixed_shadow_base, 0,
+    "If non-zero, HWASan will attempt to allocate the shadow at this address, "
+    "instead of choosing one dynamically."
+    "Tip: this can be combined with the compiler option, "
+    "-hwasan-mapping-offset, to optimize the instrumentation.")
diff --git a/compiler-rt/lib/hwasan/hwasan_linux.cpp b/compiler-rt/lib/hwasan/hwasan_linux.cpp
index 81226da976d1161..e7cf36ef3161cbf 100644
--- a/compiler-rt/lib/hwasan/hwasan_linux.cpp
+++ b/compiler-rt/lib/hwasan/hwasan_linux.cpp
@@ -106,8 +106,14 @@ static uptr GetHighMemEnd() {
 }
 
 static void InitializeShadowBaseAddress(uptr shadow_size_bytes) {
-  __hwasan_shadow_memory_dynamic_address =
-      FindDynamicShadowStart(shadow_size_bytes);
+  // NULL is generally address zero, so it is not a valid location for the
+  // shadow.
+  if (flags()->fixed_shadow_base != 0) {
+    __hwasan_shadow_memory_dynamic_address = flags()->fixed_shadow_base;
+  } else {
+    __hwasan_shadow_memory_dynamic_address =
+        FindDynamicShadowStart(shadow_size_bytes);
+  }
 }
 
 static void MaybeDieIfNoTaggingAbi(const char *message) {

[vitalybuka]

-1, not sure that none will need NULL as a base

[thurstond]

Done

[vitalybuka]

oh,and maybe some test with use of the file?

[vitalybuka]

probably linux not android only test

[thurstond]

Added compiler-rt/test/hwasan/TestCases/Linux/fixed-shadow.c

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[vitalybuka]

there is possibility to re-map critical pages with FIXED and crash the process.
Would in't be enough to do the same without FIXED and use addr is a hint?

Alternative trivial approach?

print `extern uptr __hwasan_shadow_memory_dynamic_address;`
//CHECK: expected value

[vitalybuka]

Also there is DumpProcessMap(), maybe it's easy to see shadow there?

[thurstond]

there is possibility to re-map critical pages with FIXED and crash the process. Would in't be enough to do the same without FIXED and use addr is a hint?

I've removed MAP_FIXED.

(My concern was that mmap might return addresses that are consecutive pages. In that case, this test will be useless at verifying that the entire address space can be correctly mapped to shadow memory.)

Alternative trivial approach?

print `extern uptr __hwasan_shadow_memory_dynamic_address;`
//CHECK: expected value

This will show that compiler-rt has the correct shadow address, but it doesn't prove that the compiler instrumentation is using the specified shadow base.
i.e., we want to test that -hwasan-mapping-offset and HWASAN_OPTIONS=fixed_shadow_base work together

[thurstond]

Likewise, this doesn't test the compiler instrumentation.

For example, if -hwasan-mapping-offset was not implemented properly, and the compiler instrumentation was still using the lookup in DTLS, it would defeat the purpose of a fixed shadow base, but it would still pass the DumpProcessMap() test.

[vitalybuka]

Likewise, this doesn't test the compiler instrumentation.

That's fine to focus on runtime only. E.g. GCC also runs them.

[vitalybuka]

(My concern was that mmap might return addresses that are consecutive pages. In that case, this test will be useless at verifying that the entire address space can be correctly mapped to shadow memory.)

if ((unsigned long long)p != addr) { should solve that?

[thurstond]

(My concern was that mmap might return addresses that are consecutive pages. In that case, this test will be useless at verifying that the entire address space can be correctly mapped to shadow memory.)

if ((unsigned long long)p != addr) { should solve that?

This condition ensures that a passing test implies it the shadow mapping is highly likely to be correct, and will fail if it is unsure. The condition doesn't prevent the "fail if it is unsure" case (e.g., suppose mmap keeps returning addresses in the lower 1GB of memory).

[vitalybuka]

@thurstond uptr -> uint64_t
we can compile for 64bit on 32bit platform