|
|
Message-Id: <20170810172615.51965-21-thgarnie@google.com>
Date: Thu, 10 Aug 2017 10:26:12 -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>,
Arnd Bergmann <arnd@...db.de>,
Thomas Garnier <thgarnie@...gle.com>,
Matthias Kaehlcke <mka@...omium.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Joerg Roedel <joro@...tes.org>,
Tom Lendacky <thomas.lendacky@....com>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...e.de>,
Brian Gerst <brgerst@...il.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>,
Pavel Machek <pavel@....cz>,
Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux.com>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Chris Metcalf <cmetcalf@...lanox.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Christopher Li <sparse@...isli.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Lukas Wunner <lukas@...ner.de>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
Dou Liyang <douly.fnst@...fujitsu.com>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Markus Trippelsdorf <markus@...ppelsdorf.de>,
Steven Rostedt <rostedt@...dmis.org>,
Kees Cook <keescook@...omium.org>,
Rik van Riel <riel@...hat.com>,
David Howells <dhowells@...hat.com>,
Waiman Long <longman@...hat.com>,
Kyle Huey <me@...ehuey.com>,
Peter Foley <pefoley2@...oley.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Catalin Marinas <catalin.marinas@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Michal Hocko <mhocko@...e.com>,
Matthew Wilcox <mawilcox@...rosoft.com>,
"H . J . Lu" <hjl.tools@...il.com>,
Paul Bolle <pebolle@...cali.nl>,
Rob Landley <rob@...dley.net>,
Baoquan He <bhe@...hat.com>,
Daniel Micay <danielmicay@...il.com>
Cc: x86@...nel.org,
linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org,
xen-devel@...ts.xenproject.org,
kvm@...r.kernel.org,
linux-pm@...r.kernel.org,
linux-arch@...r.kernel.org,
linux-sparse@...r.kernel.org,
kernel-hardening@...ts.openwall.com
Subject: [RFC v2 20/23] x86/pie: Add option to build the kernel as PIE for x86_64
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 -2G limit increasing the KASLR range from 1GB to 3GB.
The modules do not support PIE due to how they are linked. Disable PIE
for them and default to mcmodel=kernel for now.
The PIE configuration is not yet compatible with XEN_PVH. Xen PVH
generates 32-bit assembly and uses a long jump to transition to 64-bit.
A long jump require an absolute reference that is not compatible with
PIE.
Performance/Size impact:
Hackbench (50% and 1600% loads):
- PIE disabled: no significant change (-0.50% / +0.50%)
- PIE enabled: 7% to 8% on half load, 10% on heavy load.
These results are aligned with the different research on user-mode PIE
impact on cpu intensive benchmarks (around 10% on x86_64).
slab_test (average of 10 runs):
- PIE disabled: no significant change (-1% / +1%)
- PIE enabled: 3% to 4%
Kernbench (average of 10 Half and Optimal runs):
Elapsed Time:
- PIE disabled: no significant change (-0.22% / +0.06%)
- PIE enabled: around 0.50%
System Time:
- PIE disabled: no significant change (-0.99% / -1.28%)
- PIE enabled: 5% to 6%
Size of vmlinux (Ubuntu configuration):
File size:
- PIE disabled: 472928672 bytes (-0.000169% from baseline)
- PIE enabled: 216878461 bytes (-54.14% from baseline)
.text sections:
- PIE disabled: 9373572 bytes (+0.04% from baseline)
- PIE enabled: 9499138 bytes (+1.38% from baseline)
The big decrease in vmlinux file size is due to the lower number of
relocations appended to the file.
Signed-off-by: Thomas Garnier <thgarnie@...gle.com>
---
arch/x86/Kconfig | 7 +++++++
arch/x86/Makefile | 9 +++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2632fa8e8945..a419f4110872 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2132,6 +2132,13 @@ config X86_GLOBAL_STACKPROTECTOR
bool
depends on CC_STACKPROTECTOR
+config X86_PIE
+ bool
+ depends on X86_64 && !XEN_PVH
+ select DEFAULT_HIDDEN
+ 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 66af2704f096..05e01588b5af 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -45,8 +45,12 @@ export REALMODE_CFLAGS
export BITS
ifdef CONFIG_X86_NEED_RELOCS
+ifdef CONFIG_X86_PIE
+ LDFLAGS_vmlinux := -pie -shared -Bsymbolic
+else
LDFLAGS_vmlinux := --emit-relocs
endif
+endif
#
# Prevent GCC from generating any FP code by mistake.
@@ -141,7 +145,12 @@ else
KBUILD_CFLAGS += $(cflags-y)
KBUILD_CFLAGS += -mno-red-zone
+ifdef CONFIG_X86_PIE
+ KBUILD_CFLAGS += -fPIC
+ KBUILD_CFLAGS_MODULE += -fno-PIC -mcmodel=kernel
+else
KBUILD_CFLAGS += -mcmodel=kernel
+endif
# -funit-at-a-time shrinks the kernel .text considerably
# unfortunately it makes reading oopses harder.
--
2.14.0.434.g98096fd7a8-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.