similar to: Information about ASLR (Address Space Layout Randomization) in CentOS 5

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

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 >

> 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

+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

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

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

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

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

Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable at . Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our

Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable at . Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our

On Fri, 10 Aug 2018, Zev Weiss wrote: > Also x86_64 here (Core i7-4771, for what it's worth). I too have 4.17 > installed, I just haven't yet gotten around to actually running it, so 4.14 is > what's presently live on the system. If you want I think you should be able > to replicate that aspect via 'xbps-install linux4.14' (and then of course > booting said

Two other things: 1) I get massively more stable execution times on 16.04 than on 14.04 on both x86 and ARM because 16.04 does far fewer gratuitous moves from one core to another, even without explicit pinning. 2) turn off ASLR: "echo 0 > /proc/sys/kernel/randomize_va_space". As well as getting stable addresses for debugging repeatability, it also stabilizes execution time

On Sat, Sep 12, 2015 at 7:48 PM, Greg Stark <stark at mit.edu> wrote: > I get that even if I put -fPIE in CFLAGS. Er, yeah. Even a trivial test case doesn't work: $ cat foo.c int main(int argc, char *argv[], char *envp[]) { return 1; } $ clang -o foo -fsanitize=memory -fPIE -pie foo.c $ sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 $ ./foo FATAL: Code

On Sat, Sep 5, 2015 at 11:50 AM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 5, 2015 at 6:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > This is more like a limitation of asan, not libFuzzer. > > By design, asan does not recover from the first crash. > > This feature has been criticized quite a lot, but I am still convinced > this >

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

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

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

In various debug dumps (eg., Clang's -ast-dump), various objects (eg., Stmts and Decls in that -ast-dump) are identified by pointers. It's very reliable in the sense that no two objects would ever have the same pointer at the same time, but it's unpleasant that pointers change across runs. Having deterministic identifiers instead of pointers would aid debugging: imagine a

This RFC describes pagerando, an improvement upon ASLR for shared libraries. We're planning to submit this work for upstreaming and would appreciate feedback before we get to the patch submission stage. Pagerando randomizes the location of individual memory pages (ASLR only randomizes the library base address). This increases security against code-reuse attacks (such as ROP) by tolerating

On Sat, Jun 10, 2017 at 4:09 PM, Davide Italiano <davide at freebsd.org> wrote: > On Tue, Jun 6, 2017 at 10:55 AM, Stephen Crane via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> This RFC describes pagerando, an improvement upon ASLR for shared >> libraries. We're planning to submit this work for upstreaming and >> would appreciate feedback before we get