# Address Space Layout Randomization Next Generation
## 3 ASLR Limitations  
In this section we analyze the problems and limitations present in all ASLR implementations employed by modern operating systems. The main limitation is introduced by the fact that there are objects (e.g., stack, heap) that need to grow in memory at runtime. This requires to divide the virtual memory region to ensure that those objects can grow.  
In more detail, the Linux and PaX (FreeBSD, HardenedGentoo and others use the PaX ASLR approximation) ASLR designs rely on the same core ideas, in that they define four partial-VM areas: (1) stack, (2) libraries/mmaps, (3) executable and (4) heap. The classic memory layout was designed by considering that some zones or objects are _growable_ (main stack, thread stacks and heap). Ideally, a growable object is a contiguous area of memory which can be expanded or shrunk dynamically according to the needs of the program. In order to allow them to grow, they are typically placed in the border (top or bottom) of virtual memory, far away from other objects, otherwise they will not grow or, even worse, a silent collision could occur.  
Originally, the functionality of growable objects was a smart, simple and efficiently solution for efficient memory usage. However, the use of threaded applications and the possibility of adding dynamically new objects into the memory space forced developers to reconsider the viability of these growable areas. Today, growable objects are a source of numerous problems [29; 30], but fortunately a set of advanced programming solutions has been developed.  
Growable objects impose strong limitations on ASLR design, and they affect negatively the entropy of all objects. The situation gets even worse when multiple growable objects are used in the application, as actually happens with multiple thread stacks. The approach used in Linux (see Figure 9) involves placing each object as separately as possible from each other, which forces to fix high bits of the addresses, thus degrading effective entropy. Since the extremes of the virtual memory  
\begin{table}
\begin{tabular}{l l l} \hline \hline
**Feature** & **Description** \\ \hline \multirow{4}{*}{**Pax**} & Per-boot & Every time the system is booted. \\  & Per-exec & Every time a new image is executed. \\  & Per-fork & Every time a new process is spawned. \\  & Per-object & Every time a new object is created. \\ \hline \multirow{4}{*}{**Pax**} & Stack & Stack of the main process. \\  & LD & Dynamic linker/loader. \\  & Executable & Loadable segments (text, data, bss,...). \\  & Heap & Old-fashioned dynamic memory of the process: brk(). \\  & vDSO/VVAR & Objects exported by the kernel to the user space. \\  & ARGV & Command line arguments and environment variables of the process. \\  & Mmaps/libs & Objects allocated calling mmap(). \\ \hline \multirow{4}{*}{**Pax**} & Partial VM & A sub-range of the VM space is used to map the object. \\  & Full VM & The full VM space is used to map the object. \\  & Isolated-object & The object is randomized independently from any other. \\  & Correlated-object & The object is randomized with respect to another. \\  & Sub-page & Page offset bits are randomized. \\  & Bit-slicing & Different slices of the address are randomized at different times. \\  & Direction & Top-down/bottom-up search side used on a first-fit allocation strategy. \\  & Specific-zone & A base address and a direction where objects are allocated together. \\ \hline \hline \end{tabular}
\end{table}
Table 1: Summary of randomization forms and dimensions.  
are already occupied, libraries and mmaps are placed between the stack and the heap. Note that a small shared library is automatically mapped by the kernel into the address space of all user-space applications (vDSO). Therefore, both static and dynamically linked (PIE or not) programs have a similar memory layout.  
Originally, PIE-compiled applications were loaded jointly with the libraries, but after the Offset2 lib weakness [27] was identified, the PIE executable was moved to lower addresses (Linux 4.1) in its own zone.