[cfe-dev] Dataflow sanitizer memory mapping question

[Frederico Araujo]

Thanks for the explanations!


On Wed, May 21, 2014 at 2:06 PM, Peter Collingbourne <pcc at google.com> wrote:

>
>
>
> 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.
>

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? I anticipate that changing it is not really a good
idea :)
I'd like to find a way around my problem without touching the sanitizer's
logic.


>
>
>>> 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.
>

Ok. Thanks for the info.


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