[PATCH] D137666: [msan] Increase size of app/shadow/origin mappings on aarch64

Thu Nov 10 10:54:29 PST 2022

thurston added a comment.

In D137666#3919867 <https://reviews.llvm.org/D137666#3919867>, @eugenis wrote:

> Ah, so is the problem with ASLR randomizing the initial executable mappings over a region larger than 64Gb? We do not care about app allocating memory, heap placement is defined by msan. Could you confirm that the new mapping covers all possible locations? Even with ex. a huge executable binary.
>
> That's ok I guess, if we do not care about /39 and /42 on aarch64 linux. I'm also curious how much dynamic shadow mapping would cost (cpu and code size). It's not as straightforward as with ASan, because MSan can not allocate shadow in a single contiguous block, most likely. But it can save us a lot of pain down the road.

Yes, it is because of ASLR. The app mappings I changed are "app-14" (program segments) and "app-15" (libraries segments).

I tested the new mappings on Google3. On a corpus of 23,000 Google3 test cases:

- the original mappings (4GB for app-14, 4GB for app-15) had 8500 failures (https://mondo.corp.google.com/run/3a6eac70-9e20-4a32-abaf-64de831ecd9c)
- increasing the mappings to 64GB for app-14 and 64GB for app-15 had 1900 failures (https://mondo.corp.google.com/run/d5ae6cae-709c-4c64-8127-96d525fcf54c)
- increasing the mappings to 64GB for app-14 and 1TB for app-15 (as per this patch) had 415 failures (https://mondo.corp.google.com/run/7ba6836e-b8dc-4789-b504-ccba30354bf1); most (perhaps all?) of these remaining failures are not because of undersized memory mappings.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137666/new/

https://reviews.llvm.org/D137666