Re: [PATCH] mm/vmalloc: randomize vmalloc() allocations

[Topi Miettinen]

On 4.12.2020 15.33, David Laight wrote:
> From: Topi Miettinen
> > Sent: 04 December 2020 10:58
> >
> > On 4.12.2020 1.15, David Laight wrote:
> > > From: Mike Rapoport
> > > > Sent: 03 December 2020 06:58
> > > >
> > > > On Wed, Dec 02, 2020 at 08:49:06PM +0200, Topi Miettinen wrote:
> > > > > On 1.12.2020 23.45, Topi Miettinen wrote:
> > > > > > Memory mappings inside kernel allocated with vmalloc() are in
> > > > > > predictable order and packed tightly toward the low addresses. 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.
> > >
> > > Isn't that going to horribly fragment the available address space
> > > and make even moderate sized allocation requests fail (or sleep).
> >
> > For 32 bit architecture this is a real issue, but I don't think for 64
> > bits it will be a problem. You can't fragment the virtual memory space
> > for small allocations because the resulting page tables will not fit in
> > RAM for existing or near future systems.
>
> Hmmm truly random allocations are going to need 3 or 4 extra page tables
> on 64bit systems. A bit overhead for 4k allocates.
> While you won't run out of address space, you will run out of memory.

There are 3500 entries in /proc/vmallocinfo on my system with lots of 
BPF filters (which allocate 8kB blocks). The total memory used is 740MB. 
Assuming that every entry needed additional 4 pages, it would mean 55MB, 
or 7.4% extra. I don't think that's a problem and even if it would be in 
some case, there's still the option of not using randomize_vmalloc.

-Topi