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

[Uladzislau Rezki <urezki@gmail.com>]

On Sat, Feb 13, 2021 at 03:43:39PM +0200, Topi Miettinen wrote:
> On 13.2.2021 13.55, Uladzislau Rezki wrote:
> > > Hello,
> > > 
> > > Is there a chance of getting this reviewed and maybe even merged, please?
> > > 
> > > -Topi
> > > 
> > I can review it and help with it. But before that i would like to
> > clarify if such "randomization" is something that you can not leave?
> 
> This happens to interest me and I don't mind the performance loss since I
> think there's also an improvement in security. I suppose (perhaps wrongly)
> that others may also be interested in such features. For example, also
> `nosmt` can take away a big part of CPU processing capability.
>
OK. I was thinking about if it is done for some production systems or
some specific projects where this is highly demanded.

>
> Does this
> answer your question, I'm not sure what you mean with leaving? I hope you
> would not want me to go away and leave?
>
No-no, that was a type :) Sorry for that. I just wanted to figure out
who really needs it.

> > For example on 32bit system vmalloc space is limited, such randomization
> > can slow down it, also it will lead to failing of allocations much more,
> > thus it will require repeating with different offset.
> 
> I would not use `randomize_vmalloc=1` on a 32 bit systems, because in
> addition to slow down, the address space could become so fragmented that
> large allocations may not fit anymore. Perhaps the documentation should warn
> about this more clearly. I haven't tried this on a 32 bit system though and
> there the VM layout is very different.
> 
For 32-bit systems that would introduce many issues not limited to fragmentations.

> __alloc_vm_area() scans the vmalloc space starting from a random address up
> to end of the area. If this fails, the scan is restarted from the bottom of
> the area up to this random address. Thus the entire area is scanned.
> 
> > Second. There is a space or region for modules. Using various offsets
> > can waste of that memory, thus can lead to failing of module loading.
> 
> The allocations for modules (or BPF code) are also randomized within their
> dedicated space. I don't think other allocations should affect module space.
> Within this module space, fragmentation may also be possible because there's
> only 1,5GB available. The largest allocation on my system seems to be 11M at
> the moment, others are 1M or below and most are 8k. The possibility of an
> allocation failing probably depends on the fill ratio. In practice haven't
> seen problems with this.
> 
I think it depends on how many modules your system loads. If it is a big
system it might be that such fragmentation and wasting of module space
may lead to modules loading.

> It would be possible to have finer control, for example
> `randomize_vmalloc=3` (1 = general vmalloc, 2 = modules, bitwise ORed) or
> `randomize_vmalloc=general,modules`.
> 
> I experimented by trying to change how the modules are compiled
> (-mcmodel=medium or -mcmodel=large) so that they could be located in the
> normal vmalloc space, but instead I found a bug in the compiler (-mfentry
> produces incorrect code for -mcmodel=large, now fixed).
> 
> > On the other side there is a per-cpu allocator. Interfering with it
> > also will increase a rate of failing.
> 
> I didn't notice the per-cpu allocator before. I'm probably missing
> something, but it seems to be used for a different purpose (for allocating
> the vmap_area structure objects instead of the address space range), so
> where do you see interference?
> 


   A                       B
 ---->                   <----
<---------------------------><--------->
|   vmalloc address space    |
|<--------------------------->


A - is a vmalloc allocations;
B - is a percpu-allocator.

--
Vlad Rezki