[LLVMdev] [PATCH] Add the disable_aslr option that will disable the address space layout randomization under AddressSanitizer on 10.6

Kostya Serebryany kcc at google.com
Fri Dec 9 14:55:10 PST 2011

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.

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

More information about the llvm-dev mailing list