llvm dev - Dec 2011 - [LLVMdev] [PATCH] Add the disable_aslr option that will disable the address space layout randomization under AddressSanitizer on 10.6

On Fri, Dec 9, 2011 at 11:24 AM, Eric Christopher <echristo at
apple.com>wrote:
>
> On Dec 9, 2011, at 11:23 AM, Kostya Serebryany wrote:
>
>
>
> On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at
apple.com>wrote:
>
>>
>> On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote:
>>
>> > Yes, we have no ASRL with -no_pie.
>> > Can we disable ASRL even with -pie?
>> > On linux we can do it with "setarch x86_64 -R".
>> >
>>
>> You asked about link time. Now it sounds like you're talking about
>> runtime?
>>
>
> Link time is of course better.
> But if there is a syscall (like the one used by setarch) we could call it
> and reexec.
> Using setenv("DYLD_NO_PIE")+reexec looks gross to me.
>
>
>
> Not sure honestly.
>
Thanks. If anyone knows, please jump in.

As for the patch, I really don't like
  1. 3 different cases for 3 different flavors of MacOS. How are we goring
to support it?
  2. doing setenv+reexec. This will be a debugging nightmare for us and for
users.

I would prefer just to print a descriptive warning message and exit:
   ==123== ERROR: AddressSanitizer on MacOS requires to disable ASRL for
the executable.
   ==123== ERROR: You can do it this way:
   ==123== ERROR: <how to disable ASLR>
   ==123== ABORTING

--kcc


>
>
>> > Another question: if asan would require -no_pie on Mac, will this
be a
>> serious limitation?
>> >
>>
>> If asan required no pie on Linux, would it be a serious limitation?
>>
>
> For Linux, I don't think this will be too bad, but may cause some users
a
> bit of pain to rework their build files.
> Luckily, asan and -pie work together on Linux quite well.
> I don't know how important is "-pie" on Mac.
>
>
> Just as important as it is on Linux.
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111209/8e77350d/attachment.html>

> As for the patch, I really don't like
>   1. 3 different cases for 3 different flavors of MacOS. How are we goring
> to support it?
The first is Leopard, which we don't want to support at all. Maybe we
should check that in some other place.
The second is Snow Leopard, where ASLR is controlled by the
DYLD_NO_PIE env var, which is read by the dynamic loader.
The third is Lion, which does not support DYLD_NO_PIE, but instead
supports a flag I've mentioned above. I suppose further Mac OS
releases will support only this way.

There also is the MH_PIE bit in the Mach-O header, which we can flip
to disable ASLR. But I'm not sure whether it won't disable the PIE
behavior at all.
Also, we'll need some special tool for that.
>   2. doing setenv+reexec. This will be a debugging nightmare for us and for
> users.
One can avoid setenv+exec by setting disable_aslr to 0. In this case
we can print the big warning (if someone wants to run the binary under
GDB, ASLR will anyway be disabled).
>
> I would prefer just to print a descriptive warning message and exit:
>    ==123== ERROR: AddressSanitizer on MacOS requires to disable ASRL for
the
> executable.
>    ==123== ERROR: You can do it this way:
>    ==123== ERROR: <how to disable ASLR>
>    ==123== ABORTING
"pass the no_pie to your linker"
We can do this in the Clang driver, but a proper fix will involve
removing all the instances of -pie from the arg list.
I've recently posted a question about that to cfe-dev, but
unfortunately nobody responded.

BTW, have you given up the idea of having zero offset for the shadow?
We'll need PIE for that.

On Fri, Dec 9, 2011 at 12:00 PM, Alexander Potapenko <glider at
google.com>wrote:
> > As for the patch, I really don't like
> >   1. 3 different cases for 3 different flavors of MacOS. How are we
> goring
> > to support it?
> The first is Leopard, which we don't want to support at all. Maybe we
> should check that in some other place.
> The second is Snow Leopard, where ASLR is controlled by the
> DYLD_NO_PIE env var, which is read by the dynamic loader.
> The third is Lion, which does not support DYLD_NO_PIE, but instead
> supports a flag I've mentioned above. I suppose further Mac OS
> releases will support only this way.
>
> There also is the MH_PIE bit in the Mach-O header, which we can flip
> to disable ASLR. But I'm not sure whether it won't disable the PIE
> behavior at all.
> Also, we'll need some special tool for that.
>
> >   2. doing setenv+reexec. This will be a debugging nightmare for us
and
> for
> > users.
> One can avoid setenv+exec by setting disable_aslr to 0. In this case
> we can print the big warning (if someone wants to run the binary under
> GDB, ASLR will anyway be disabled).
> >
> > I would prefer just to print a descriptive warning message and exit:
> >    ==123== ERROR: AddressSanitizer on MacOS requires to disable ASRL
for
> the
> > executable.
> >    ==123== ERROR: You can do it this way:
> >    ==123== ERROR: <how to disable ASLR>
> >    ==123== ABORTING
> "pass the no_pie to your linker"
> We can do this in the Clang driver, but a proper fix will involve
> removing all the instances of -pie from the arg list.
> I've recently posted a question about that to cfe-dev, but
> unfortunately nobody responded.
>
> BTW, have you given up the idea of having zero offset for the shadow?
> We'll need PIE for that.
>
The zero offset (which speeds up asan by ~6%) requires PIE, but also
requires no ASLR.

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111209/b9fc2774/attachment.html>