kernel-hardening - Re: [PATCH v6 2/4] x86/modules: Increase randomization for modules

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1537824509.19013.63.camel@intel.com>
Date: Mon, 24 Sep 2018 21:27:59 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "keescook@...omium.org" <keescook@...omium.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"daniel@...earbox.net" <daniel@...earbox.net>, "arjan@...ux.intel.com"
	<arjan@...ux.intel.com>, "jannh@...gle.com" <jannh@...gle.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "alexei.starovoitov@...il.com"
	<alexei.starovoitov@...il.com>, "kernel-hardening@...ts.openwall.com"
	<kernel-hardening@...ts.openwall.com>, "Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [PATCH v6 2/4] x86/modules: Increase randomization for modules

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@...el.com> 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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.