|
|
Message-Id: <20171004212003.28296-26-thgarnie@google.com>
Date: Wed, 4 Oct 2017 14:20:01 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
"David S . Miller" <davem@...emloft.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Garnier <thgarnie@...gle.com>,
Arnd Bergmann <arnd@...db.de>,
Kees Cook <keescook@...omium.org>,
Matthias Kaehlcke <mka@...omium.org>,
Tom Lendacky <thomas.lendacky@....com>,
Andy Lutomirski <luto@...nel.org>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Borislav Petkov <bp@...e.de>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>,
Pavel Machek <pavel@....cz>,
Juergen Gross <jgross@...e.com>,
Chris Wright <chrisw@...s-sol.org>,
Alok Kataria <akataria@...are.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Chris Metcalf <cmetcalf@...lanox.com>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Borislav Petkov <bp@...en8.de>,
"Luis R . Rodriguez" <mcgrof@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Christopher Li <sparse@...isli.org>,
Steven Rostedt <rostedt@...dmis.org>,
Jason Baron <jbaron@...mai.com>,
Dou Liyang <douly.fnst@...fujitsu.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Lukas Wunner <lukas@...ner.de>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Joerg Roedel <joro@...tes.org>,
Rik van Riel <riel@...hat.com>,
David Howells <dhowells@...hat.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Waiman Long <longman@...hat.com>,
Kyle Huey <me@...ehuey.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Jonathan Corbet <corbet@....net>,
Matthew Wilcox <mawilcox@...rosoft.com>,
Michal Hocko <mhocko@...e.com>,
Peter Foley <pefoley2@...oley.com>,
Paul Bolle <pebolle@...cali.nl>,
Jiri Kosina <jkosina@...e.cz>,
Rob Landley <rob@...dley.net>,
"H . J . Lu" <hjl.tools@...il.com>,
Baoquan He <bhe@...hat.com>,
Jan H . Schönherr <jschoenh@...zon.de>,
Daniel Micay <danielmicay@...il.com>
Cc: x86@...nel.org,
linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
xen-devel@...ts.xenproject.org,
linux-arch@...r.kernel.org,
linux-sparse@...r.kernel.org,
kvm@...r.kernel.org,
linux-doc@...r.kernel.org,
kernel-hardening@...ts.openwall.com
Subject: [RFC v3 25/27] x86/pie: Add option to build the kernel as PIE
Add the CONFIG_X86_PIE option which builds the kernel as a Position
Independent Executable (PIE). The kernel is currently build with the
mcmodel=kernel option which forces it to stay on the top 2G of the
virtual address space. With PIE, the kernel will be able to move below
the current limit.
The --emit-relocs linker option was kept instead of using -pie to limit
the impact on mapped sections. Any incompatible relocation will be
catch by the arch/x86/tools/relocs binary at compile time.
Performance/Size impact:
Size of vmlinux (Default configuration):
File size:
- PIE disabled: +0.000031%
- PIE enabled: -3.210% (less relocations)
.text section:
- PIE disabled: +0.000644%
- PIE enabled: +0.837%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: -0.201%
- PIE enabled: -0.082%
.text section:
- PIE disabled: same
- PIE enabled: +1.319%
Size of vmlinux (Default configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +0.814%
Size of vmlinux (Ubuntu configuration + ORC):
File size:
- PIE enabled: -3.167%
.text section:
- PIE enabled: +1.26%
The size increase is mainly due to not having access to the 32-bit signed
relocation that can be used with mcmodel=kernel. A small part is due to reduced
optimization for PIE code. This bug [1] was opened with gcc to provide a better
code generation for kernel PIE.
Hackbench (50% and 1600% on thread/process for pipe/sockets):
- PIE disabled: no significant change (avg +0.1% on latest test).
- PIE enabled: between -0.50% to +0.86% in average (default and Ubuntu config).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-2% on latest run, likely noise).
- PIE enabled: between -1% and +0.8% on latest runs.
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (avg -0.239%)
- PIE enabled: average +0.07%
System Time:
- PIE disabled: no significant change (avg -0.277%)
- PIE enabled: average +0.7%
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82303
Signed-off-by: Thomas Garnier <thgarnie@...gle.com>
---
arch/x86/Kconfig | 8 ++++++++
arch/x86/Makefile | 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1e4b399c64e5..b92f96923712 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2141,6 +2141,14 @@ config X86_GLOBAL_STACKPROTECTOR
bool
depends on CC_STACKPROTECTOR
+config X86_PIE
+ bool
+ depends on X86_64
+ select DEFAULT_HIDDEN
+ select DYNAMIC_MODULE_BASE
+ select MODULE_REL_CRCS if MODVERSIONS
+ select X86_GLOBAL_STACKPROTECTOR if CC_STACKPROTECTOR
+
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 42774185a58a..c49855b4b1be 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -144,6 +144,7 @@ else
KBUILD_CFLAGS += -mno-red-zone
ifdef CONFIG_X86_PIE
+ KBUILD_CFLAGS += -fPIC
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/x86/kernel/module.lds
else
KBUILD_CFLAGS += -mcmodel=kernel
--
2.14.2.920.gcf0c67979c-goog
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.