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? And what do others think of the proposal?
