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

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

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

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

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

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

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

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

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

Hi, We are porting some applications from CentOS 4 to CentOS 5, the applications use mmap, and we found out that they sometimes crash in CentOS 5. We found out that this is due to the fact that CentOS 5 does randomization of the address space when loading binaries, libraries, and when using mmap, so that is what's causing our problem. The thing is, I'm trying to google for it, but I did

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

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

On Mon, Jun 12, 2017 at 1:03 PM, Stephen Crane <sjc at immunant.com> wrote: > I don't have performance measurements for the new LTO version of > pagerando yet. I'll definitely be thoroughly measuring performance > once the current prototype is finished before moving forward, and will > post results when I have them. > > I'm definitely curious about your work

> On Jun 14, 2017, at 2:47 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 15 Jun 2017, at 6:50 AM, Louis Gerbarg <lgerbarg at apple.com <mailto:lgerbarg at apple.com>> wrote: >> >>> >>> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

I could understand a TLB hit if functions that originally happened to be on the same page were spread across many pages, raising the iTLB footprint for a given loop, etc. (reduced spatial locality). For pagerando, since we're splitting on 4k page boundaries and can keep spatial locality (or attempt to improve it), I'm not sure that TLB misses will be a large factor. I expect that the

On Tue, Mar 03, 2020 at 01:19:22PM -0800, Kees Cook wrote: > On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi wrote: > > On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > > > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz at infradead.org> > > > > But,... do we still need this in the light of that fine-grained > > >