On Wed, 2018-06-20 at 15:33 -0700, Kees Cook wrote: > > The new __vmalloc_node_try_addr function uses the existing function > > __vmalloc_node_range, in order to introduce this algorithm with the > > least > > invasive change. The side effect is that each time there is a > > collision when > > trying to allocate in the random area a TLB flush will be > > triggered. There is > > a more complex, more efficient implementation that can be used > > instead if > > there is interest in improving performance. > The only time when module loading speed is noticeable, I would think, > would be boot time. Have you done any boot time delta analysis? I > wouldn't expect it to change hardly at all, but it's probably a good > idea to actually test it. :) Thanks, I'll do some tests. > Also: can this be generalized for use on other KASLRed architectures? > For example, I know the arm64 module randomization is pretty similar > to x86. I started in the x86/kernel/module.c because that was where the existing implementation was, but I don't know of any reason why it could not apply to other architectures in general. The randomness estimates would be different if module size probability distribution, module space size or module alignment are different.
