[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6e7e4191612460ba96567c16b4171f2d2f91b296.camel@linux.intel.com>
Date: Tue, 03 Mar 2020 13:01:26 -0800
From: Kristen Carlson Accardi <kristen@...ux.intel.com>
To: Thomas Garnier <thgarnie@...omium.org>, Peter Zijlstra
<peterz@...radead.org>
Cc: Kees Cook <keescook@...omium.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>,
"H. Peter Anvin" <hpa@...or.com>, 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 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>
Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
