[cfe-dev] Dataflow sanitizer memory mapping question

[Peter Collingbourne]

On Wed, May 21, 2014 at 12:25 PM, Frederico Araujo <araujof at gmail.com>wrote:

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

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

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.

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