On Sat, Feb 13, 2021 at 03:43:39PM +0200, Topi Miettinen wrote:

On 13.2.2021 13.55, Uladzislau Rezki wrote:

quoted

quoted

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.

quoted

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.

quoted

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).

quoted

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