All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Kees Cook <keescook@chromium.org>,
	Kristen Carlson Accardi <kristen@linux.intel.com>
Cc: Thomas Garnier <thgarnie@chromium.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	the arch/x86 maintainers <x86@kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Juergen Gross <jgross@suse.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	"VMware, Inc." <pv-drivers@vmware.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Jiri Slaby <jslaby@suse.cz>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Cao jin <caoj.fnst@cn.fujitsu.com>,
	Allison Randal <allison@lohutok.net>,
	Linux.Crypto@zytor.com
Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
Date: Wed, 04 Mar 2020 01:40:15 -0800	[thread overview]
Message-ID: <202003040940.0249eM5n306088@mail.zytor.com> (raw)
In-Reply-To: <202003031314.1AFFC0E@keescook>

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

On March 3, 2020 1:19:22 PM PST, Kees Cook <keescook@chromium.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@infradead.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.

      parent reply	other threads:[~2020-03-04  9:42 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28  0:00 [PATCH v11 00/11] x86: PIE support to extend KASLR randomization Thomas Garnier
2020-02-28  0:00 ` Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 01/11] x86/crypto: Adapt assembly for PIE support Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 02/11] x86: Add macro to get symbol address " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 03/11] x86: relocate_kernel - Adapt assembly " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 04/11] x86/entry/64: " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 05/11] x86: pm-trace - " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 06/11] x86/CPU: " Thomas Garnier
2020-03-03  4:58   ` Kees Cook
2020-02-28  0:00 ` [PATCH v11 07/11] x86/acpi: " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 08/11] x86/boot/64: " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 09/11] x86/power/64: " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 10/11] x86/paravirt: " Thomas Garnier
2020-02-28  0:00 ` [PATCH v11 11/11] x86/alternatives: " Thomas Garnier
2020-03-03  4:59   ` Kees Cook
2020-03-03  5:02 ` [PATCH v11 00/11] x86: PIE support to extend KASLR randomization Kees Cook
2020-03-03  5:02   ` Kees Cook
2020-03-03  9:55   ` Peter Zijlstra
2020-03-03  9:55     ` Peter Zijlstra
2020-03-03 15:43     ` Thomas Garnier
2020-03-03 15:43       ` Thomas Garnier
2020-03-03 15:43       ` Thomas Garnier
2020-03-03 21:01       ` Kristen Carlson Accardi
2020-03-03 21:01         ` Kristen Carlson Accardi
2020-03-03 21:01         ` Kristen Carlson Accardi
2020-03-03 21:19         ` Kees Cook
2020-03-03 21:19           ` Kees Cook
2020-03-04  9:21           ` Peter Zijlstra
2020-03-04  9:21             ` Peter Zijlstra
2020-03-04 18:21             ` Kees Cook
2020-03-04 18:21               ` Kees Cook
2020-03-04 18:44               ` H. Peter Anvin
2020-03-04 18:44                 ` H. Peter Anvin
2020-03-04 19:19                 ` Thomas Garnier
2020-03-04 19:19                   ` Thomas Garnier
2020-03-04 19:19                   ` Thomas Garnier
2020-03-04 19:22                   ` H. Peter Anvin
2020-03-04 19:22                     ` H. Peter Anvin
2020-03-04  9:40           ` H. Peter Anvin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202003040940.0249eM5n306088@mail.zytor.com \
    --to=hpa@zytor.com \
    --cc=Linux.Crypto@zytor.com \
    --cc=allison@lohutok.net \
    --cc=ardb@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kristen@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=pv-drivers@vmware.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=thellstrom@vmware.com \
    --cc=thgarnie@chromium.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.