linux-kernel - Re: [PATCH v8 0/4] 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: <84597c620c39ed17be11de759646f3ace3e236fa.camel@intel.com>
Date:   Wed, 7 Nov 2018 20:03:40 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "willy@...radead.org" <willy@...radead.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "arjan@...ux.intel.com" <arjan@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "kristen@...ux.intel.com" <kristen@...ux.intel.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 v8 0/4] KASLR feature to randomize each loadable module

On Tue, 2018-11-06 at 13:04 -0800, Andrew Morton wrote:
> On Fri,  2 Nov 2018 12:25:16 -0700 Rick Edgecombe <rick.p.edgecombe@...el.com>
> wrote:
> 
> > This is V8 of the "KASLR feature to randomize each loadable module"
> > patchset.
> > The purpose is to increase the randomization and also to make the modules
> > randomized in relation to each other instead of just the base, so that if
> > one
> > module leaks the location of the others can't be inferred.
> 
> I'm not seeing any info here which explains why we should add this to
> Linux.
> 
> What is the end-user value?  What problems does it solve?  Are those
> problems real or theoretical?  What are the exploit scenarios and how
> realistic are they?  etcetera, etcetera.  How are we to decide to buy
> this thing if we aren't given a glossy brochure?
Hi Andrew,

Thanks for taking a look! The first version had a proper write up, but now the
details are spread out over 8 versions. I'll send out another version with it
all in one place.

The short version is that today the RANDOMIZE_BASE feature randomizes the base
address where the module allocations begin with 10 bits of entropy. From here,
a highly deterministic algorithm allocates space for the modules as they are 
loaded and un-loaded. If an attacker can predict the order and identities for
modules that will be loaded, then a single text address leak can give the
attacker access to the locations of all the modules. 

So this is trying to prevent the same class of attacks as the existing KASLR,
like control flow manipulation and now also making it harder/longer to find
speculative execution gadgets. It increases the number of possible
positions 128X, and with that amount of randomness per module instead of for all
modules.

> > There is a small allocation performance degradation versus v7 as a
> > trade off, but it is still faster on average than the existing
> > algorithm until >7000 modules.
> 
> lol.  How did you test 7000 modules?  Using the selftest code?

Yes, this is with simulations using the included kselftest code with sizes
extracted from the x86_64 in-tree modules. Supporting 7000 kernel modules is not
the intention though, instead it's trying to accommodate 7000 allocations in the
module space. So also eBPF JIT, classic BPF socket filter JIT, kprobes, etc.