[PATCH v2 0/4] Improved ASLR

[Rich Felker]

On Thu, Dec 03, 2020 at 10:43:29AM +0200, Topi Miettinen wrote:
> On 3.12.2020 1.09, Rich Felker wrote:
> >On Sat, Nov 28, 2020 at 01:59:41PM +0200, Topi Miettinen via Libc-alpha wrote:
> >>Problem with using sbrk() for allocations is that the location of the
> >>memory is relatively predicatable since it's always located next to
> >>data segment. This series makes the tunables system, malloc() and TCB
> >>use mmap() instead, except when instructed by tunable
> >>glibc.malloc.use_sbrk.
> >
> >The above description is contrary to present reality on Linux. With
> >kernel.randomize_va_space=2 (default), the brk area starts at a
> >randomize gap above end of data/bss. This is *stronger* ASLR than
> >mmap, which aside from the initial gap, generally appears just below
> >the previous map and thereby at a predictable offset from an anchor in
> >a shared library.
> 
> Thanks for the review. I'd note that the randomization for brk is
> only 12 bits, so it's still relatively predictable. With
> randomize_va_space=3, the randomization provided by mmap() will be
> much better, the maximum allowed by the kernel design. The best in
> all cases would be if randomize_va_space=3 could be detected by libc
> and then it would change the default choice between brk() and mmap()
> automatically, or libc could generate a random address by itself and
> use mmap(random_addr,, MAP_FIXED_NOREPLACE) instead of brk(). For
> example, kernel could use aux vectors to pass the information.

Why isn't the proposed randomize_va_space=3 kernel patch just
using a completely random base for brk region (and reserving at least
a few GB for it to grow into)? Then all existing programs would get
the benefit.

Rich