Re: [PATCH v3] mm/vmalloc: randomize vmalloc() allocations
From: Topi Miettinen
Date: Sat Mar 06 2021 - 01:26:57 EST
On 6.3.2021 3.13, Andrew Morton wrote:
On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen <toiwoton@xxxxxxxxx> wrote:
Memory mappings inside kernel allocated with vmalloc() are in
predictable order and packed tightly toward the low addresses, except
for per-cpu areas which start from top of the vmalloc area. With
new kernel boot parameter 'randomize_vmalloc=1', the entire area is
used randomly to make the allocations less predictable and harder to
guess for attackers. Also module and BPF code locations get randomized
(within their dedicated and rather small area though) and if
CONFIG_VMAP_STACK is enabled, also kernel thread stack locations.
On 32 bit systems this may cause problems due to increased VM
fragmentation if the address space gets crowded.
On all systems, it will reduce performance and increase memory and
cache usage due to less efficient use of page tables and inability to
merge adjacent VMAs with compatible attributes. On x86_64 with 5 level
page tables, in the worst case, additional page table entries of up to
4 pages are created for each mapping, so with small mappings there's
considerable penalty.
...
How useful is this expected to be? What sort of attack scenarios will
this help to defend against?
Since there's a clear trade-off between best performance and additional
address space randomization, this will not be useful for those who
prefer performance. That's also why this is not the default but has to
be enabled with a boot parameter.
For those who are willing to pay the price for additional hardening, the
purpose is to make attacks against KASLR (similar to TagBleed [1]) more
difficult since the targeted memory locations may reside anywhere in the
32 TB vmalloc region and knowing one address does not reveal the others.
[1] https://download.vusec.net/papers/tagbleed_eurosp20.pdf
-Topi