Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v4] mm: Optional full ASLR for mmap() and mremap()
To:     Matthew Wilcox <willy@infradead.org>
Cc:     linux-hardening@vger.kernel.org, akpm@linux-foundation.org,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Jann Horn <jannh@google.com>,
        Kees Cook <keescook@chromium.org>,
        Mike Rapoport <rppt@kernel.org>
References: <20201026160518.9212-1-toiwoton@gmail.com>
 <20201117165455.GN29991@casper.infradead.org>
From:   Topi Miettinen <toiwoton@gmail.com>
Message-ID: <19373af5-2272-7615-27a7-6734c584f8bd@gmail.com>
Date:   Tue, 17 Nov 2020 22:21:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <20201117165455.GN29991@casper.infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 17.11.2020 18.54, Matthew Wilcox wrote:
> On Mon, Oct 26, 2020 at 06:05:18PM +0200, Topi Miettinen wrote:
>> Writing a new value of 3 to /proc/sys/kernel/randomize_va_space
>> enables full randomization of memory mappings created with mmap(NULL,
>> ...). With 2, the base of the VMA used for such mappings is random,
>> but the mappings are created in predictable places within the VMA and
>> in sequential order. With 3, new VMAs are created to fully randomize
>> the mappings. Also mremap(..., MREMAP_MAYMOVE) will move the mappings
>> even if not necessary.
> 
> Is this worth it?
> 
> https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/aslrcache-practical-cache-attacks-mmu/

Thanks, very interesting. The paper presents an attack (AnC) which can 
break ASLR even from JavaScript in browsers. In the process it compares 
the memory allocators of Firefox and Chrome. Firefox relies on Linux 
mmap() to randomize the memory location, but Chrome internally chooses 
the randomized address. The paper doesn't present exact numbers to break 
ASLR for Chrome case, but it seems to require more effort. Chrome also 
aggressively randomizes the memory on each allocation, which seems to 
enable further possibilities for AnC to probe the MMU tables.

Disregarding the difference in aggressiveness of memory allocators, I 
think with sysctl.kernel.randomize_va_space=3, the effort for breaking 
ASLR with Firefox should be increased closer to Chrome case since mmap() 
will use the address space more randomly.

I have used this setting now for a month without any visible performance 
issues, so I think the extra bits (for some additional effort to 
attackers) are definitely worth the low cost.

Furthermore, the paper does not describe in detail how the attack would 
continue after breaking ASLR. Perhaps there are assumptions which are 
not valid when the different memory areas are no longer sequential. For 
example, if ASLR is initially broken wrt. the JIT buffer but continuing 
the attack would require other locations to be determined (like stack, 
data segment for main exe or libc etc), further efforts may be needed to 
resolve these locations. With randomize_va_space=2, resolving any 
address (JIT buffer) can reveal the addresses of many other memory areas 
but this is not the case with 3.

-Topi