<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 21, 2014 at 12:25 PM, Frederico Araujo <span dir="ltr"><<a href="mailto:araujof@gmail.com" target="_blank">araujof@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the explanations!<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Wed, May 21, 2014 at 2:06 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:pcc@google.com" target="_blank">pcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Wed, May 21, 2014 at 11:57 AM, Frederico Araujo <span dir="ltr"><<a href="mailto:araujof@gmail.com" target="_blank">araujof@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks for the prompt reply!<div><br></div>
<div class="gmail_extra"><div class="gmail_quote"><div>
On Wed, May 21, 2014 at 12:12 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">+pcc<br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Wed, May 21, 2014 at 8:59 PM, Frederico Araujo <span dir="ltr"><<a href="mailto:araujof@gmail.com" target="_blank">araujof@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I created an example program to learn how to use the clang dataflow sanitizer and noticed that when the program is compiled with the -fsanitize=dataflow option, the application and its shared libraries are mapped differently to memory. My question is why the program section is relocated to higher addresses and shared objects appear to be relocated below the heap?</div>
</div></blockquote><div><br></div></div><div>This happens because -fsanitize=dataflow implies -pie which changes the mapping the way you describe. </div><div>tsan (--fsanitize=tread) and msan (-fsanitize=memory) behave the same way. </div>
<div>This is intentional, such mapping makes the implementation more efficient. </div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div> For instance, see below the two memory maps for the same program compiled without/with the dataflow sanitizer option.</div>
<div><br></div><div>Is this necessary for the memory shadowing mechanism used by the sanitizer? I'd really appreciate if someone could explain the design decision behind these remappings. </div><div>Ultimately, I'd like to know if it's possible to keep the program mapped to its original low addresses without hurting the dataflow sanitizer assumptions.<br>
</div></div></blockquote><div><br></div></div><div>for msan not using -pie would be a significant performance hit, and dfsan is rather similar to msan. <br></div><div>pcc, please correct me if I am wrong. </div><div>for tsan this will be less of an issue, but still undesirable. </div>
</div></div></div></blockquote><div><br></div></div><div>I understand the performance issues. But say I wanted to disable it to perform some tests, what should I do to disable it (I tried passing -fno-pie to clang, but it's not working probably because of -fsanitize=dataflow, which forces -pie during linking)?</div>
</div></div></div></blockquote><div><br></div></div><div>You would need to change how dfsan does shadow address mapping. Currently dfsan uses the lower 32TB of the process's address space for shadow memory. If you disable PIE, Linux will allocate the binary's data in the same part of the address space, which will conflict with shadow memory.</div>
</div></div></div></blockquote><div><br></div></div><div>Correct me if I'm wrong, but this mapping strategy allows for the efficient look up of shadow locations through masking and shifting of the application memory addresses, right?</div>
</div></div></div></blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I anticipate that changing it is not really a good idea :) </div>
<div>I'd like to find a way around my problem without touching the sanitizer's logic.</div></div></div></div></blockquote><div><br></div><div>Linux doesn't give you much control over where processes are mapped to. As far as I know, you will either need to keep PIE enabled or change the mapping strategy -- something has to give.</div>
<div><br></div><div>Peter</div></div></div></div>