[PATCH] D23354: [compiler-rt] Support dynamic shadow address instrumentation

[Chris Hamilton via llvm-commits]

As a further data point:

We wish to eventually ship a version of ASAN to 64-bit canary windows users
of Chrome, like we do with 32-bit SyzyASAN. Any mechanism that uses a
static shadow address has to work 100% of the time for all users, otherwise
it's simply not able to be shipped. A hack that works in the lab under
controlled conditions isn't good enough for something we want to ship to
end users.

On Wed, 10 Aug 2016 at 15:44 Etienne Bergeron <etienneb at google.com> wrote:

> etienneb marked 2 inline comments as done.
> etienneb added a comment.
>
> In https://reviews.llvm.org/D23354#511569, @kcc wrote:
>
> > Wait, wait, this utterly sucks.
> >  I need to know that we've exhausted all other possibilities before
> reviewing this.
> >  Did we?
>
>
> Windows memory implementation is not compatible with a static shadow
> address space without using ugly hacks.
>
> The shadow address spaces currently used for win64 is working on windows
> 10 but not on windows 7.
> On different windows version, the address space size is not the same (8 TB
> vs 128 TB).
> see:
> https://msdn.microsoft.com/en-ca/library/windows/desktop/aa366778(v=vs.85).aspx
>
> When using a static address within the 8TB, there is no way to be sure the
> memory space is available.
> The DLLs are loaded at random location. The high-entropy randomisation is
> activated and DLLs are loaded everywhere in the memory space.
>
> see: https://msdn.microsoft.com/en-us/library/jj835761.aspx
>
>   /HIGHENTROPYVA
>   By default, the linker sets this option for 64-bit executable images.
>
> I was able to make it work with a static shadow (within the 8TB limit),
> but executables need to turn off the high-entropy, which is a hack.
> Turning off high-entropy is not recommended and even if it's working I
> can't guaranty it will always work. We observed that DLLs where
> loaded in the lower address space.
>
> After trying to find different way to hack the code to keep a static
> shadow, we decided to try the dynamic one and determine if it's working
> and what is the extra cost added.
>
> The only added cost is a load at every instrumented-function entry.
> There is an added loaded and a register holding the shadow address is used;
> which I believe won't make a huge difference.
>
> Benchmark will come. I wanted to share this solution to start discussion.
>
>
> https://reviews.llvm.org/D23354
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160810/4025c876/attachment.html>