On 29 Mar 2018, at 00:07, Luck, Tony [off-list ref] wrote:
=20

quoted

The default limit of only 65536 VMAs will also quickly come into play
if consecutive anon mmaps don't get merged. Of course this can be
raised, but it has significant resource and performance (fork) costs.

=20
Could the random mmap address chooser look for how many existing
VMAs have space before/after and the right attributes to merge with =

the

new one you want to create? If this is above some threshold (100?) =

then

pick one of them randomly and allocate the new address so that it will
merge from below/above with an existing one.
=20
That should still give you a very high degree of randomness, but =

prevent

out of control numbers of VMAs from being created.

I think this wouldn=E2=80=99t work. For example these 100 allocation may =
happened on=20
process initialization. But when attacker come to the server all his=20
allocations would be made on the predictable offsets from each other. So =
in=20
result we did nothing just decrease performance of first 100 =
allocations. I=20
think I can make ioctl to turn off this randomization per process and it =
could=20
be used if needed. For example if application going to allocate big =
chunk or=20
make big memory pressure, etc.

Best regards,
Ilya