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

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

Another question: if asan would require -no_pie on Mac, will this be a
serious limitation?

Thanks,

--kcc

On Fri, Dec 9, 2011 at 11:07 AM, Eric Christopher <echristo at
apple.com>wrote:
>    Options when creating a main executable
>      -pie        This makes a special kind of main executable that is
> position
>                  independent (PIE).  On Mac OS X 10.5 and later, the OS
> the OS
>                  will load a PIE at a random address each time it is
> executed.
>                  You cannot create a PIE from .o files compiled with -mdy-
>                  namic-no-pic.  That means the codegen is less optimal, but
>                  the address randomization adds some security. When
> targeting
>                  Mac OS X 10.7 or later PIE is the default for main
> executa-
>                  bles.
>
>      -no_pie     Do not make a position independent executable (PIE).
>  This is
>                  the default, when targeting 10.6 and earlier.
>
> On Dec 9, 2011, at 11:02 AM, Kostya Serebryany wrote:
>
> +llvmdev
>
> Question to MacOS gurus: is there a way to disable ASLR (address space
> layout randomization) on Darwin at link time
> instead of doing setenv("DYLD_NO_PIE", "1", 1); and
reexec?
>
> Thanks,
>
> --kcc
>
> On Fri, Dec 9, 2011 at 4:28 AM, Alexander Potapenko <glider at
google.com>wrote:
>
>> The attached patch introduces the disable_aslr option (off by default)
>> and the corresponding AsanDisableAslr function that should disable the
>> address space randomization.
>> This is now implemented for Mac OS 10.6 only.
>> In order to do this we add DYLD_NO_PIE=1 to the env and restart the
>> program.
>>
>> Next steps to be done are:
>>  -- check for MH_PIE bit -- if it is 0, we don't need to disable
anything;
>>  -- use posix_spawnattr_setflags() to set the _POSIX_SPAWN_DISABLE_ASLR
>> on 10.7
>>  -- disable ASLR on Linux, if needed.
>>
>> --
>> Alexander Potapenko
>> Software Engineer
>> Google Moscow
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111209/212320d2/attachment.html>

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

-eric

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>