This is an archive of the discontinued LLVM Phabricator instance.

[Asan] Introduce the concept of physical shadow memory
AbandonedPublic

Authored by kosarev on Apr 3 2017, 1:47 AM.

Diff Detail

Event Timeline

kosarev created this revision.Apr 3 2017, 1:47 AM
filcab edited edge metadata.Apr 11 2017, 9:38 AM

Please make the commit message descriptive for people doing git blame (or svn blame) later.

lib/asan/asan_mapping.h
208

While you're touching these lines, maybe align them with the ones above by removing the space before define and adding spaces before MEM_TO_VSHADOW?

kosarev updated this revision to Diff 95138.Apr 13 2017, 8:47 AM

Updated as suggested.

Please make the commit message descriptive for people doing git blame (or svn blame) later.

Right, will do. Thanks for reminding.

kosarev updated this revision to Diff 97234.Apr 30 2017, 7:59 AM

This patch introduces a class of shadow pointers designed to be the interface to physical shadow memory. The idea behind shadow pointers is to encapsulate the physical memory mechanics so that:

  • sequential accesses to the same shadow page do not cause extra virtual-to-physical address translations, thus providing acceptable performance in the MMU-less mode and
  • sanitizer developers are not forced to take care of the organization of physical memory when dealing with shadow accesses.

This patch intentionally includes (not-yet-committed) D31395 so one could apply and test it if necessary. Once generally accepted, I will remove those common parts and update the patch.

dvyukov edited edge metadata.May 1 2017, 3:58 AM

This patch introduces a class of shadow pointers designed to be the interface to physical shadow memory. The idea behind shadow pointers is to encapsulate the physical memory mechanics so that:

  • sequential accesses to the same shadow page do not cause extra virtual-to-physical address translations, thus providing acceptable performance in the MMU-less mode and
  • sanitizer developers are not forced to take care of the organization of physical memory when dealing with shadow accesses.

This patch intentionally includes (not-yet-committed) D31395 so one could apply and test it if necessary. Once generally accepted, I will remove those common parts and update the patch.

Previously we discussed an option of mapping continuous shadow for continuous user regions. That would not require any changes to asan/msan/tsan core code.
Until we evaluated that idea and decided that it's completely infeasible, I don't like approach in this patch.

Understood. Will let you know if there are issues with the allocations-intercepting approach. Thanks.

kosarev abandoned this revision.Nov 28 2017, 8:52 AM

Intercepting of allocations worked well for us. Thanks Dmitry.