ASLR disabled by default - thoughts?

[I’m not seeing this show up in the archives two hours after I posted it from my google account, so I’m sending it from my gmail account. Pardon if this shows up again in the next 24 hours from my @[google.com](http://google.com) account…]

Mailing lists were down for a few hours. :slight_smile:

Yes it should be disabled by default for all systems. It is this was on MacOSX by default. The linux plug-in will need to be fixed.

Is ASLR per-launch / per-process on other platforms?

Linux allows you to set it per process, and based on previous comments, MacOSX does as well (there’s a posix_spawn flag for it on that platform). You can disable it on Linux at the kernel level, but that’s not how we want to use it in this scenario.

You don’t have a way to disable it just for a process on Windows?

-Todd

You can disable it on Linux at the kernel level, but that’s not how we want to use it in this scenario.

Meaning it can be done system-wide, but that’s not how we plan to use it on Linux.

Correct, AFAIK the only way to disable ASLR in Windows is:

a) Editing a registry setting which will require a reboot and be system-wide
b) Compiling your executable with a specific flag which has been set to enable ASLR by default since VS 2012.
c) Using the EMET utility (untested, but I guess should work). Regardless, it’s a manual step and would require elevation (aka sudo)

Maybe it’s just because I’m used to an environment where ASLR is per-boot, but what are the issues with debugging when ASLR is enabled? Source/line breakpoints can just be resolved every time you debug. Same with symbol breakpoints. Even absolute address breakpoints can be translated to Module+offset and persist across ASLR. The only things I can think of off the top of my head are hardware data breakpoints, and printing addresses to log files. Is there other stuff that is complicated by ASLR?

Watchpoints on heap-allocated memory (whether software or hardware).

The address breakpoints don't currently resolve to section+offset and then re-resolve themselves that way, though that would be a good addition.

But mostly it avoids the cognitive load of having "the same things be different" when you are going a number of rounds trying to chase a problem down.

Jim

So your JIT'ed code on the heap will always end up at the same location as well? That is a pretty big gamble.