Increasing the range of address-space layout randomization

re fragmentation, with the region based approach there is no fragmentation beyond what the vanilla kernel causes. what does change is the inter-region gap size which limits the maximum size of mmap requests that can fit since that gap changes on each run. to reduce *that* effect, PaX limits the randomization applied to the MSBs. my non-scientific rule-of-thumb is to leave the 4 MSBs undisturbed, that is, the largest gap changes by at most 1/8th of the address space size which in practice means that any app running into trouble with it would likely have problems regardless of ASLR.

> Specific exploits *may* reduce this, depending upon the details.

yes, i tend to describe the limits of any given defense mechanism, in case of ASLR it's obvious what the lower limit is, the less obvious case is the upper limit (of the entropy a given attack may have to overcome). any real life case will fall somewhere in-between and let's not forget about the attack detection/reaction mechanism that is also part of the ASLR design (which bounds the probability of success) that is mostly omitted in other implementations.

> When you mention for ROP you need to know the stack address, is that for the case where you don't have a stack overflow that takes over a return instruction?

well, when i speak of ROP, i actually mean 'execute existing code out of original program order' (see pax.txt about the threat model) which these days is called 'code reuse attack', i.e., it's the general case, not a specific one for just controlling a return address. in any case, when you think of the stack buffer overflow case, to pass a pointer parameter to a function where the (attacker-provided) data is also on the stack somewhere then you somehow need to learn that stack address. whether that requires learning the stack entropy or just some offsetting a register via gadgets depends on the situation.

> If I get time to take a wack at it, would a patch against the document be welcome?

sure but i'd appreciate an update on the implementation details even more ;).

> Also, is there any other benefits to your ASLR implementation versus upstream's?

if there wasn't any, i wouldn't still be maintaining my code after all these years ;). one obvious benefit is the much more concise and understandable implementation, there're basically 4 per-arch constants (PAX_DELTA_*) that will tell you what region gets randomized by how much, no need for reimplementing the effectively same helper functions for each arch as vanilla does. there're also finer details like handling corner cases on address space exhaustion or randomizing PIEs or disallowing the runtime control of ASLR (PF_RANDOMIZE) or safer brk randomization, etc.