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

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

--kcc

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

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.
> 
> > 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/aef109ba/attachment.html>

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>

> 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.
There's posix_spawnattr_setflags() that can do the job
(http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/),
but the necessary flag appeared only in Lion.

To the best of my knowledge, there's no link-time option that disables
ASLR but keeps PIE on Snow Leopard or Lion.
At the moment we're using DYLD_NO_PIE with Chromium binaries to
disable ASLR at runtime.

On Dec 9, 2011, at 11:46 AM, Alexander Potapenko wrote:
>> 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.
> There's posix_spawnattr_setflags() that can do the job
> (http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/),
> but the necessary flag appeared only in Lion.
> 
> To the best of my knowledge, there's no link-time option that disables
> ASLR but keeps PIE on Snow Leopard or Lion.
> At the moment we're using DYLD_NO_PIE with Chromium binaries to
> disable ASLR at runtime.
One bit that may make sense is to support the newest (Lion) style and give
a descriptive error message for the other two cases? I.e. if we notice that
MH_PIE is set in the executable, but we're not on Lion and we don't have
DYLD_NO_PIE set in the environment give an error?

Or some combination of this.

-eric