Page MenuHomePhabricator

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

Authored by luismarques on Feb 28 2021, 4:11 PM.

Details

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.

Diff Detail

Event Timeline

luismarques created this revision.Feb 28 2021, 4:11 PM
luismarques requested review of this revision.Feb 28 2021, 4:11 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptFeb 28 2021, 4:11 PM
Herald added subscribers: llvm-commits, Restricted Project. · View Herald Transcript
vitalybuka accepted this revision.Mar 5 2021, 12:12 PM
vitalybuka added 1 blocking reviewer(s): EccoTheDolphin.

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

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?

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

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

MaskRay added inline comments.
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."?

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 accepted this revision.EditedMar 31 2021, 8:11 AM

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.

This revision was not accepted when it landed; it landed in state Needs Review.Apr 6 2021, 12:46 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.