[cfe-dev] Dataflow sanitizer memory mapping question

[Peter Collingbourne]

On Wed, May 21, 2014 at 11:57 AM, Frederico Araujo <araujof at gmail.com>wrote:

> Thanks for the prompt reply!
>
> On Wed, May 21, 2014 at 12:12 PM, Kostya Serebryany <kcc at google.com>wrote:
>
>> +pcc
>>
>>
>> On Wed, May 21, 2014 at 8:59 PM, Frederico Araujo <araujof at gmail.com>wrote:
>>
>>> Hi,
>>>
>>> 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?
>>>
>>
>> This happens because -fsanitize=dataflow implies -pie which changes the
>> mapping the way you describe.
>> tsan (--fsanitize=tread) and msan (-fsanitize=memory) behave the same
>> way.
>> This is intentional, such mapping makes the implementation more
>> efficient.
>>
>>
>>>  For instance, see below the two memory maps for the same program
>>> compiled without/with the dataflow sanitizer option.
>>>
>>> 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.
>>> 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.
>>>
>>
>> for msan not using -pie would be a significant performance hit, and dfsan
>> is rather similar to msan.
>> pcc, please correct me if I am wrong.
>> for tsan this will be less of an issue, but still undesirable.
>>
>
> 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)?
>

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.


>> Why does this bother you?
>>
>
> The problem is that I believe this remapping could be interfering with
> another component of a project I've been working on, which takes snapshots
> of a running application. But I'm not completely sure about it yet.
>
> Does dfsan maps the 64 Terabytes of virtual address space like msan?
>

Yes, and this would be independent of whether dfsan uses PIE.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140521/9cacf7d5/attachment.html>