<div dir="ltr">I've debated turning on some of these features by default but I find it to be a bit of a hard sell because these mechanisms just don't protect well against modern attacks.  The randomization is not sufficient, but making it large enough to be sufficient also creates a massive fragmentation problem for any program that mmap()'s and munmap()'s a ton of stuff.<div><br></div><div>Actually, the one I'd really like to implement is support for the execute-disable bit on the stack.  No point turning on ASLR or PIE without that.  It would be a minor project for someone.  We already support the pmap bit, but the protection map doesn't map VM_PROT_EXECUTE and the ELF loader's mappings might be a bit off, too.<div><br></div><div>Unfortunately, none of these mechanisms (not even the ED bit) really mitigate exploits, which should be obvious simply by observing the insane number of machines out in the wild that have viruses.  The only real protection is to reduce the network-facing attack surface as much as possible and to segregate clients.  That's 99% of security.  1% of it is something like ASLR or PIE or ED.  In some respects, these mitigations are their own worse enemy because they create a false sense of security.</div><div><br></div><div>The biggest looming problem we have can't be protected by ED, ASLR, PIE, or any other OS-supported mechanism.   The biggest looming problem are attacks against interpreters and scripting languages, and side-band attacks against dynamic ram and cpu caches.  Not just SQL injection or java byte code attacks, but so many programs these days integrate interpreters of one sort or another into their operation that attacking the interpreter is becoming easier and easier.  Side-band attacks are even more dangerous as those can be used to suss-out encryption keys and (for the DRAM attack) to directly bypass all known protective mechanisms.</div><div><div><div><br></div><div>-Matt<br>​</div></div></div></div></div>