[PATCH v2 0/4] Improved ASLR

[Topi Miettinen]

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.

-Topi