[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171004212003.28296-11-thgarnie@google.com>
Date: Wed, 4 Oct 2017 14:19:46 -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 10/27] x86/boot/64: Adapt assembly for PIE support
Change the assembly code to use only relative references of symbols for the
kernel to be PIE compatible.
Early at boot, the kernel is mapped at a temporary address while preparing
the page table. To know the changes needed for the page table with KASLR,
the boot code calculate the difference between the expected address of the
kernel and the one chosen by KASLR. It does not work with PIE because all
symbols in code are relatives. Instead of getting the future relocated
virtual address, you will get the current temporary mapping. The solution
is using global variables that will be relocated as expected.
Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.
Signed-off-by: Thomas Garnier <thgarnie@...gle.com>
---
arch/x86/kernel/head_64.S | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 42e32c2e51bb..32d1899f48df 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -86,8 +86,21 @@ startup_64:
popq %rsi
/* Form the CR3 value being sure to include the CR3 modifier */
- addq $(early_top_pgt - __START_KERNEL_map), %rax
+ addq _early_top_pgt_offset(%rip), %rax
jmp 1f
+
+ /*
+ * Position Independent Code takes only relative references in code
+ * meaning a global variable address is relative to RIP and not its
+ * future virtual address. Global variables can be used instead as they
+ * are still relocated on the expected kernel mapping address.
+ */
+ .align 8
+_early_top_pgt_offset:
+ .quad early_top_pgt - __START_KERNEL_map
+_init_top_offset:
+ .quad init_top_pgt - __START_KERNEL_map
+
ENTRY(secondary_startup_64)
UNWIND_HINT_EMPTY
/*
@@ -116,7 +129,7 @@ ENTRY(secondary_startup_64)
popq %rsi
/* Form the CR3 value being sure to include the CR3 modifier */
- addq $(init_top_pgt - __START_KERNEL_map), %rax
+ addq _init_top_offset(%rip), %rax
1:
/* Enable PAE mode, PGE and LA57 */
@@ -131,7 +144,7 @@ ENTRY(secondary_startup_64)
movq %rax, %cr3
/* Ensure I am executing from virtual addresses */
- movq $1f, %rax
+ movabs $1f, %rax
jmp *%rax
1:
UNWIND_HINT_EMPTY
@@ -230,11 +243,12 @@ ENTRY(secondary_startup_64)
* REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
* address given in m16:64.
*/
- pushq $.Lafter_lret # put return address on stack for unwinder
+ leaq .Lafter_lret(%rip), %rax
+ pushq %rax # put return address on stack for unwinder
xorq %rbp, %rbp # clear frame pointer
- movq initial_code(%rip), %rax
+ leaq initial_code(%rip), %rax
pushq $__KERNEL_CS # set correct cs
- pushq %rax # target address in negative space
+ pushq (%rax) # target address in negative space
lretq
.Lafter_lret:
END(secondary_startup_64)
--
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.
