On Mon, 2018-09-24 at 12:58 -0700, Kees Cook wrote: > On Mon, Sep 24, 2018 at 11:57 AM, Edgecombe, Rick P > <rick.p.edgecombe@xxxxxxxxx> wrote: > > > Instead of having two open-coded __vmalloc_node_range() calls left in > > > this after the change, can this be done in terms of a call to > > > try_module_alloc() instead? I see they're slightly different, but it > > > might be nice for making the two paths share more code. > > Not sure what you mean. Across the whole change, there is one call > > to __vmalloc_node_range, and one to __vmalloc_node_try_addr. > I guess I meant the vmalloc calls -- one for node_range and one for > node_try_addr. I was wondering if the logic could be combined in some > way so that the __vmalloc_node_range() could be made in terms of the > the helper that try_module_randomize_each() uses. But this could just > be me hoping for nice-to-read changes. ;) > > -Kees One thing I had been considering was to move the whole "try random locations, then use backup" logic to vmalloc.c, and just have parameters for random area size, number of tries, etc. This way it could be possibly be re-used for other architectures for modules. Also on our list is to look at randomizing vmalloc space (especially stacks), which may or may not involve using a similar method. So maybe bit pre-mature refactoring, but would also clean up the code in module.c. Do you think it would be worth it? Thanks, Rick
