[ASan][RISCV] Fix RISC-V memory mapping

[luismarques]

Summary

Fixes the ASan RISC-V memory mapping (originally introduced by D87580 and D87581). This should be an improvement both in terms of first principles soundness and observed test failures --- test failures would occur non-deterministically depending on the ASLR random offset.

On RISC-V Linux (64-bit), TASK_UNMAPPED_BASE is currently defined as PAGE_ALIGN(TASK_SIZE / 3). The non-power-of-two divisor makes the result be the not very round number 0x1555556000. That address had to be further rounded to ensure page alignment after the shadow scale shifting is applied. Still, that value explains why the mapping table may look less regular than expected.

Further cleanups:

• Moved the mapping table comment, to ensure that the two Linux/AArch64 tables stayed together;
• Removed mention of Sv48. Neither the original mapping nor this one are compatible with an actual Linux Sv48 address space (mainline Linux still operates Sv48 in Sv39 mode). A future patch can improve this;
• Removed the additional comments, for consistency.

[vitalybuka]

LGTM, but better if someone with RISCV experience checks this too

[luismarques]

In D97646#2607526, @vitalybuka wrote:

LGTM, but better if someone with RISCV experience checks this too

I would certainly appreciate such feedback, but perhaps this should be committed now/soon. Here's why I think so:

• In personal correspondence with @EccoTheDolphin I had confirmed that the current mapping RISC-V mapping needed cleaning/fixing, and that the current values had been adjusted to deal with a specific test system situation that isn't representative.
• Two weeks ago in the RISC-V community sync-up call we also brought attention to this patch. It seems less likely now that additional feedback will be provided.
• We know that some things are broken without this patch. With it, we're currently not aware of any issue or reason to believe it's incorrect.
• We can always further improve on this patch later if it still isn't quite correct.

@EccoTheDolphin Are you able to review this in the near/medium term?

[vitalybuka]

In D97646#2631822, @luismarques wrote:

In D97646#2607526, @vitalybuka wrote:

LGTM, but better if someone with RISCV experience checks this too

It's rather recommendation then requirement. Feel free to commit as is.

[MaskRay]

compiler-rt/lib/asan/asan_mapping.h

75

Nit: Is Sv39 is a standard abbreviation?

76

Question: 0x1555550000 instead of 0x1555560000 because of "hat address had to be further rounded to ensure page alignment after the shadow scale shifting is applied. Still, that value explains why the mapping table may look less regular than expected."?

[luismarques]

In D97646#2632810, @vitalybuka wrote:

It's rather recommendation then requirement. Feel free to commit as is.

My point is that I wanted to check that the reasons I provided were actually compelling. If that's not the case then we can wait.

compiler-rt/lib/asan/asan_mapping.h

75

Nit: Is Sv39 is a standard abbreviation?

Yes. (It's in the RISC-V Privileged Spec)

76

0x1555550000 instead of 0x1555560000 is the further rounding that ensures it's still page-aligned after the shadow scale shifting, yes.
The division by 3 (of 0x4000000000, a value that isn't "cleanly" divided by 3) causes the irregular-looking table, compared with other tables. The additional alignment isn't enough to make it much more regular. Sorry if the comment wasn't very clear.

[asb]

LGTM. Luis is the one who's dived deep into the memory mappings etc, but he and I had a discussion offline to help me understand the reasoning for this change, and given it's also had an LGTM from sanitizer devs I think this is good to land.

[joshua-arch1]

This comment was removed by joshua-arch1.

compiler-rt/lib/asan/asan_mapping.h

 //
 // Default Linux/MIPS64 mapping:
 // || `[0x4000000000, 0xffffffffff]` || HighMem    ||
 // || `[0x2800000000, 0x3fffffffff]` || HighShadow ||
 // || `[0x2400000000, 0x27ffffffff]` || ShadowGap  ||
 // || `[0x2000000000, 0x23ffffffff]` || LowShadow  ||
 // || `[0x0000000000, 0x1fffffffff]` || LowMem     ||
 //
+// Default Linux/RISCV64 Sv39 mapping:
+// || `[0x1555550000, 0x3fffffffff]` || HighMem    ||
+// || `[0x0fffffa000, 0x1555555fff]` || HighShadow ||
+// || `[0x0effffa000, 0x0fffff9fff]` || ShadowGap  ||
+// || `[0x0d55550000, 0x0effff9fff]` || LowShadow  ||
+// || `[0x0000000000, 0x0d5554ffff]` || LowMem     ||
+//
 // Default Linux/AArch64 (39-bit VMA) mapping:
 // || `[0x2000000000, 0x7fffffffff]` || highmem    ||
 // || `[0x1400000000, 0x1fffffffff]` || highshadow ||
 // || `[0x1200000000, 0x13ffffffff]` || shadowgap  ||
 // || `[0x1000000000, 0x11ffffffff]` || lowshadow  ||
 // || `[0x0000000000, 0x0fffffffff]` || lowmem     ||
 //
-// RISC-V has only 38 bits for task size
-// Low mem size is set with kRiscv64_ShadowOffset64 in
-// compiler-rt/lib/asan/asan_allocator.h and in
-// llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp with
-// kRiscv64_ShadowOffset64, High mem top border is set with
-// GetMaxVirtualAddress() in
-// compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
-// Default Linux/RISCV64 Sv39/Sv48 mapping:
-// || `[0x000820000000, 0x003fffffffff]` || HighMem    ||
-// || `[0x000124000000, 0x00081fffffff]` || HighShadow ||
-// || `[0x000024000000, 0x000123ffffff]` || ShadowGap  ||
-// || `[0x000020000000, 0x000023ffffff]` || LowShadow  ||
-// || `[0x000000000000, 0x00001fffffff]` || LowMem     ||
-//
 // Default Linux/AArch64 (42-bit VMA) mapping:
 // || `[0x10000000000, 0x3ffffffffff]` || highmem    ||
 // || `[0x0a000000000, 0x0ffffffffff]` || highshadow ||
 // || `[0x09000000000, 0x09fffffffff]` || shadowgap  ||
 // || `[0x08000000000, 0x08fffffffff]` || lowshadow  ||
 // || `[0x00000000000, 0x07fffffffff]` || lowmem     ||
 //
 // Default Linux/S390 mapping:

 static const u64 kDefaultShadowScale = SANITIZER_MYRIAD2 ? 5 : 3;
 #endif
 static const u64 kDefaultShadowSentinel = ~(uptr)0;
 static const u64 kDefaultShadowOffset32 = 1ULL << 29;  // 0x20000000
 static const u64 kDefaultShadowOffset64 = 1ULL << 44;
 static const u64 kDefaultShort64bitShadowOffset =
     0x7FFFFFFF & (~0xFFFULL << kDefaultShadowScale);  // < 2G.
 static const u64 kAArch64_ShadowOffset64 = 1ULL << 36;
-static const u64 kRiscv64_ShadowOffset64 = 0x20000000;
+static const u64 kRiscv64_ShadowOffset64 = 0xd55550000;
 static const u64 kMIPS32_ShadowOffset32 = 0x0aaa0000;
 static const u64 kMIPS64_ShadowOffset64 = 1ULL << 37;
 static const u64 kPPC64_ShadowOffset64 = 1ULL << 44;
 static const u64 kSystemZ_ShadowOffset64 = 1ULL << 52;
 static const u64 kSPARC64_ShadowOffset64 = 1ULL << 43;  // 0x80000000000
 static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30;  // 0x40000000
 static const u64 kFreeBSD_ShadowOffset64 = 1ULL << 46;  // 0x400000000000
 static const u64 kNetBSD_ShadowOffset32 = 1ULL << 30;  // 0x40000000

llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp

 static const uint64_t kSmallX86_64ShadowOffsetBase = 0x7FFFFFFF;  // < 2G.
 static const uint64_t kSmallX86_64ShadowOffsetAlignMask = ~0xFFFULL;
 static const uint64_t kLinuxKasan_ShadowOffset64 = 0xdffffc0000000000;
 static const uint64_t kPPC64_ShadowOffset64 = 1ULL << 44;
 static const uint64_t kSystemZ_ShadowOffset64 = 1ULL << 52;
 static const uint64_t kMIPS32_ShadowOffset32 = 0x0aaa0000;
 static const uint64_t kMIPS64_ShadowOffset64 = 1ULL << 37;
 static const uint64_t kAArch64_ShadowOffset64 = 1ULL << 36;
-static const uint64_t kRISCV64_ShadowOffset64 = 0x20000000;
+static const uint64_t kRISCV64_ShadowOffset64 = 0xd55550000;
 static const uint64_t kFreeBSD_ShadowOffset32 = 1ULL << 30;
 static const uint64_t kFreeBSD_ShadowOffset64 = 1ULL << 46;
 static const uint64_t kNetBSD_ShadowOffset32 = 1ULL << 30;
 static const uint64_t kNetBSD_ShadowOffset64 = 1ULL << 46;
 static const uint64_t kNetBSDKasan_ShadowOffset64 = 0xdfff900000000000;
 static const uint64_t kPS4CPU_ShadowOffset64 = 1ULL << 40;
 static const uint64_t kWindowsShadowOffset32 = 3ULL << 28;
 static const uint64_t kEmscriptenShadowOffset = 0;