<div dir="ltr">As a further data point:<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 10 Aug 2016 at 15:44 Etienne Bergeron <<a href="mailto:etienneb@google.com">etienneb@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">etienneb marked 2 inline comments as done.<br>
etienneb added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D23354#511569" rel="noreferrer" target="_blank">https://reviews.llvm.org/D23354#511569</a>, @kcc wrote:<br>
<br>
> Wait, wait, this utterly sucks.<br>
>  I need to know that we've exhausted all other possibilities before reviewing this.<br>
>  Did we?<br>
<br>
<br>
Windows memory implementation is not compatible with a static shadow address space without using ugly hacks.<br>
<br>
The shadow address spaces currently used for win64 is working on windows 10 but not on windows 7.<br>
On different windows version, the address space size is not the same (8 TB vs 128 TB).<br>
see: <a href="https://msdn.microsoft.com/en-ca/library/windows/desktop/aa366778(v=vs.85).aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-ca/library/windows/desktop/aa366778(v=vs.85).aspx</a><br>
<br>
When using a static address within the 8TB, there is no way to be sure the memory space is available.<br>
The DLLs are loaded at random location. The high-entropy randomisation is activated and DLLs are loaded everywhere in the memory space.<br>
<br>
see: <a href="https://msdn.microsoft.com/en-us/library/jj835761.aspx" rel="noreferrer" target="_blank">https://msdn.microsoft.com/en-us/library/jj835761.aspx</a><br>
<br>
  /HIGHENTROPYVA<br>
  By default, the linker sets this option for 64-bit executable images.<br>
<br>
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.<br>
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<br>
loaded in the lower address space.<br>
<br>
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<br>
and what is the extra cost added.<br>
<br>
The only added cost is a load at every instrumented-function entry.<br>
There is an added loaded and a register holding the shadow address is used;<br>
which I believe won't make a huge difference.<br>
<br>
Benchmark will come. I wanted to share this solution to start discussion.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D23354" rel="noreferrer" target="_blank">https://reviews.llvm.org/D23354</a><br>
<br>
<br>
<br>
</blockquote></div>