[PATCH v2 0/4] Improved ASLR

[Rich Felker]

On Thu, Dec 03, 2020 at 06:05:56PM +0200, Topi Miettinen wrote:
> On 3.12.2020 17.26, Rich Felker wrote:
> >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.
> 
> Great idea! I'll try to add that to the patch set.

Great! FYI we also use brk in musl libc's mallocng as a source of
memory for metadata areas that are expected not the be at predictable
offset from any module's text or data segment or from heap allocations
(which all come from mmap), so increased randomization for its
location will help a lot.

As a related aside, you probably need to recommend increasing
vm.max_map_count with kernel.randomize_va_space==3. Otherwise it
becomes pretty easy to hit the default VMA limit of 64k.

Rich