From: Kees Cook <keescook@chromium.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kristen Carlson Accardi <kristen@linux.intel.com>,
Thomas Garnier <thgarnie@chromium.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>,
"H. Peter Anvin" <hpa@zytor.com>,
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 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>
Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
Date: Wed, 4 Mar 2020 10:21:48 -0800 [thread overview]
Message-ID: <202003041019.C6386B2F7@keescook> (raw)
In-Reply-To: <20200304092136.GI2596@hirez.programming.kicks-ass.net>
On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote:
> But at what cost; it does unspeakable ugly to the asm. And didn't a
> kernel compiled with the extended PIE range produce a measurably slower
> kernel due to all the ugly?
Was that true? I thought the final results were a wash and that earlier
benchmarks weren't accurate for some reason? I can't find the thread
now. Thomas, do you have numbers on that?
BTW, I totally agree that fgkaslr is the way to go in the future. I
am mostly arguing for this under the assumption that it doesn't
have meaningful performance impact and that it gains the kernel some
flexibility in the kinds of things it can do in the future. If the former
is not true, then I'd agree, the benefit needs to be more clear.
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kristen Carlson Accardi <kristen@linux.intel.com>,
Thomas Garnier <thgarnie@chromium.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>,
"H. Peter Anvin" <hpa@zytor.com>,
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
Subject: Re: [PATCH v11 00/11] x86: PIE support to extend KASLR randomization
Date: Wed, 4 Mar 2020 10:21:48 -0800 [thread overview]
Message-ID: <202003041019.C6386B2F7@keescook> (raw)
In-Reply-To: <20200304092136.GI2596@hirez.programming.kicks-ass.net>
On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote:
> But at what cost; it does unspeakable ugly to the asm. And didn't a
> kernel compiled with the extended PIE range produce a measurably slower
> kernel due to all the ugly?
Was that true? I thought the final results were a wash and that earlier
benchmarks weren't accurate for some reason? I can't find the thread
now. Thomas, do you have numbers on that?
BTW, I totally agree that fgkaslr is the way to go in the future. I
am mostly arguing for this under the assumption that it doesn't
have meaningful performance impact and that it gains the kernel some
flexibility in the kinds of things it can do in the future. If the former
is not true, then I'd agree, the benefit needs to be more clear.
--
Kees Cook
next prev parent reply other threads:[~2020-03-04 18:21 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 [this message]
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
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=202003041019.C6386B2F7@keescook \
--to=keescook@chromium.org \
--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=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=jslaby@suse.cz \
--cc=kernel-hardening@lists.openwall.com \
--cc=kristen@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--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=virtualization@lists.linux-foundation.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.