Alternate title: "It's Probably Fine: Continuing to Ship Unsafe Programs by Pretending ROP Doesn't Exist".
Also, if there is a defense against ROP and other exploits that makes it possible to do away with ASLR and ESP please let me know.
Memory safety.
Everything else (ASLR, DEP, CFI, heap hardening, etc.) is just fiddling around the edges -- it's not an engineering approach that produces reliable or safe software.
Security is not a binary on off thing. The harder you make it for the attacker, the better.
(however ALSR makes it difficult to deal with core dumps, ouch)
A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. (Unless you find some dlopen, exec or system, perhaps mmap with unsafely handled flags.) Add good NX and read only pages and it becomes a real puzzle.
And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need.
How often does that actually happen? On macOS and Windows the answer should be "never" since the syscall ABI is not stable...
Last time they did a major break there is in Windows 2000. I recommend reading up on how LPC works.
There have been extensions though. Such as very useful pico processes in Windows 10... Major extensions in Vista too, related to security and async operation.
I recommend j00ru's blog as a good starting point. And of course Windows Internals books.
Dear Golang...
#define WINAPI __stdcall
I didn't quite get that: the core dump is just a dump of (some of) the memory mappings of the dumped process. in my experience gdb often does not manage to make sense of it (with ALSR). (one replacement strategy is to suspend a faulting process with SIGSTOP so that it is possible to attach to it later on)
https://software.intel.com/en-us/blogs/2016/06/09/intel-rele...