linux-kernel - Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization

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: <202003040940.0249eM5n306088@mail.zytor.com>
Date:   Wed, 04 Mar 2020 01:40:15 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Kees Cook <keescook@...omium.org>,
        Kristen Carlson Accardi <kristen@...ux.intel.com>
CC:     Thomas Garnier <thgarnie@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        the arch/x86 maintainers <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Juergen Gross <jgross@...e.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        "VMware, Inc." <pv-drivers@...are.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Will Deacon <will@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jiri Slaby <jslaby@...e.cz>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Cao jin <caoj.fnst@...fujitsu.com>,
        Allison Randal <allison@...utok.net>, Linux.Crypto@...or.com
Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization

Mailing List <linux-crypto@...r.kernel.org>,LKML <linux-kernel@...r.kernel.org>,virtualization@...ts.linux-foundation.org,Linux PM list <linux-pm@...r.kernel.org>
From: hpa@...or.com
Message-ID: <F35C8DBD-9AC3-46F2-9043-6CB9A4FDDDC9@...or.com>

On March 3, 2020 1:19:22 PM PST, Kees Cook <keescook@...omium.org> wrote:
>On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi
>wrote:
>> On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote:
>> > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra
><peterz@...radead.org>
>> > wrote:
>> > > On Mon, Mar 02, 2020 at 09:02:15PM -0800, Kees Cook wrote:
>> > > > On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote:
>> > > > > Minor changes based on feedback and rebase from v10.
>> > > > > 
>> > > > > Splitting the previous serie in two. This part contains
>> > > > > assembly code
>> > > > > changes required for PIE but without any direct dependencies
>> > > > > with the
>> > > > > rest of the patchset.
>> > > > > 
>> > > > > Note: Using objtool to detect non-compliant PIE relocations
>is
>> > > > > not yet
>> > > > > possible as this patchset only includes the simplest PIE
>> > > > > changes.
>> > > > > Additional changes are needed in kvm, xen and percpu code.
>> > > > > 
>> > > > > Changes:
>> > > > >  - patch v11 (assembly);
>> > > > >    - Fix comments on x86/entry/64.
>> > > > >    - Remove KASLR PIE explanation on all commits.
>> > > > >    - Add note on objtool not being possible at this stage of
>> > > > > the patchset.
>> > > > 
>> > > > This moves us closer to PIE in a clean first step. I think
>these
>> > > > patches
>> > > > look good to go, and unblock the work in kvm, xen, and percpu
>> > > > code. Can
>> > > > one of the x86 maintainers pick this series up?
>> > > 
>> > > But,... do we still need this in the light of that fine-grained
>> > > kaslr
>> > > stuff?
>> > > 
>> > > What is the actual value of this PIE crud in the face of that?
>> > 
>> > If I remember well, it makes it easier/better but I haven't seen a
>> > recent update on that. Is that accurate Kees?
>> 
>> I believe this patchset is valuable if people are trying to brute
>force
>> guess the kernel location, but not so awesome in the event of
>> infoleaks. In the case of the current fgkaslr implementation, we only
>> randomize within the existing text segment memory area - so with PIE
>> the text segment base can move around more, but within that it
>wouldn't
>> strengthen anything. So, if you have an infoleak, you learn the base
>> instantly, and are just left with the same extra protection you get
>> without PIE.
>
>Right -- PIE improves both non- and fg- KASLR similarly, in the sense
>that the possible entropy for base offset is expanded. It also opens
>the
>door to doing even more crazy things. (e.g. why keep the kernel text
>all
>in one contiguous chunk?)
>
>And generally speaking, it seems a nice improvement to me, as it gives
>the kernel greater addressing flexibility.

The difference in entropy between fgkaslr and extending the kernel to the PIC memory model (which is the real thing this is doing) is immense:

The current kASLR has maybe 9 bits of entropy. PIC-model could extend that by at most 16 bits at considerable cost in performance and complexity. Fgkaslr would provide many kilobits worth of entropy; the limiting factor would be the random number source used! With a valid RNG, no two boots across all the computers in the world across all time would have an infinitesimal probability of ever being the same; never mind the infoleak issue.

In addition to the combinatorics, fgkaslr pushes randomization right as well as left, so even for the address of any one individual function you get a gain of 15-17 bits.

"More is better" is a truism, but so is Amdahl's Law.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.