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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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