linux-kernel - Re: [PATCH 0/3] KASLR feature to randomize each loadable module

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: <1529607389.29548.198.camel@intel.com>
Date:   Thu, 21 Jun 2018 18:56:13 +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>,
        "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Accardi, Kristen C" <kristen.c.accardi@...el.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [PATCH 0/3] KASLR feature to randomize each loadable module

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.