Address Space Layout Randomization (ASLR) provides a barrier to exploitation of 
user-space processes in the presence of security vulnerabilities by making it 
more difficult to find desired code/data which could help an attack. This is 
done by adding a random offset to the location of regions in the process 
address space, with a greater range of potential offset values corresponding to 
better protection/a larger search-space for brute force, but also to greater 
potential for fragmentation.

The offset added to the mmap_base address, which provides the basis for the 
majority of the mappings for a process, is set once on process exec in 
arch_pick_mmap_layout() and is done via hard-coded per-arch values, which 
reflect, hopefully, the best compromise for all systems. The trade-off between 
increased entropy in the offset value generation and the corresponding 
increased variability in address space fragmentation is not absolute, however, 
and some platforms may tolerate higher amounts of entropy. This patch 
introduces both new Kconfig values and a sysctl interface which may be used to 
change the amount of entropy used for offset generation on a system.

The direct motivation for this change was in response to the libstagefright 
vulnerabilities that affected Android, specifically to information provided by 
Google's project zero at:

The attack presented therein, by Google's project zero, specifically targeted 
the limited randomness used to generate the offset added to the mmap_base 
address in order to craft a brute-force-based attack. Concretely, the attack 
was against the mediaserver process, which was limited to respawning every 5 
seconds, on an arm device. The hard-coded 8 bits used resulted in an average 
expected success rate of defeating the mmap ASLR after just over 10 minutes 
(128 tries at 5 seconds a piece). With this patch, and an accompanying increase 
in the entropy value to 16 bits, the same attack would take an average expected 
time of over 45 hours (32768 tries), which makes it both less feasible and more 
likely to be noticed.

The introduced Kconfig and sysctl options are limited by per-arch minimum and 
maximum values, the minimum of which was chosen to match the current hard-coded 
value and the maximum of which was chosen so as to give the greatest 
flexibility without generating an invalid mmap_base address, generally a 3-4 
bits less than the number of bits in the user-space accessible virtual address 

When decided whether or not to change the default value, a system developer 
should consider that mmap_base address could be placed anywhere up to 2^(value) 
bits away from the non-randomized location, which would introduce 
variable-sized areas above and below the mmap_base address such that the 
maximum vm_area_struct size may be reduced, preventing very large allocations.

Changes in v6:
* re-added the (void *) casts in kernel/sysctl.c

* corrected arm64 #ifdef missing '#' typo
* removed arm64 'if MMU' Kconfig qualifiers
* corrected ARCH_MMAP_RND_BITS_MIN by subtracting 1 from the previous value
* added comment w/formula used for generating ARCH_MMAP_RND_BITS_MAX values

dcashman (4):
  mm: mmap: Add new /proc tunable for mmap_base ASLR.
  arm: mm: support ARCH_MMAP_RND_BITS.
  arm64: mm: support ARCH_MMAP_RND_BITS.
  x86: mm: support ARCH_MMAP_RND_BITS.

 Documentation/sysctl/vm.txt | 29 +++++++++++++++++++
 arch/Kconfig                | 68 +++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/Kconfig            |  9 ++++++
 arch/arm/mm/mmap.c          |  3 +-
 arch/arm64/Kconfig          | 33 ++++++++++++++++++++++
 arch/arm64/mm/mmap.c        |  8 ++++--
 arch/x86/Kconfig            | 16 +++++++++++
 arch/x86/mm/mmap.c          | 12 ++++----
 include/linux/mm.h          | 11 ++++++++
 kernel/sysctl.c             | 22 +++++++++++++++
 mm/mmap.c                   | 12 ++++++++
 11 files changed, 213 insertions(+), 10 deletions(-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Reply via email to