[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240307143027.206179-6-ardb+git@google.com>
Date: Thu, 7 Mar 2024 15:30:28 +0100
From: Ard Biesheuvel <ardb+git@...gle.com>
To: linux-kernel@...gle.com
Cc: Ard Biesheuvel <ardb@...nel.org>, Kevin Loughlin <kevinloughlin@...gle.com>,
Tom Lendacky <thomas.lendacky@....com>, Dionna Glaze <dionnaglaze@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>,
Arnd Bergmann <arnd@...db.de>, Kees Cook <keescook@...omium.org>, Brian Gerst <brgerst@...il.com>,
linux-kernel@...r.kernel.org
Subject: [RFC PATCH v6.10 0/4] x86: Rid .head.text of all abs references
From: Ard Biesheuvel <ardb@...nel.org>
Questions below!
This series removes the last remaining absolute symbol references from
head.text. Doing so is necessary because code in this section may be
called from a 1:1 mapping of memory, which deviates from the mapping
this code was linked and/or relocated to run at. This is not something
that the toolchains support: even PIC/PIE code is still assumed to
execute from the same mapping that it was relocated to run from by the
startup code or dynamic loader. This means we are basically on our own
here, and need to add measures to ensure the code works as expected in
this manner. (This work was inspired by boot problems on Clang-built
SEV-SNP guest kernels, where the confusion between RIP-relative and
absolute references was causing variable accesses to fault)
Given that the startup code needs to create the kernel virtual mapping
in the page tables, early references to some kernel virtual addresses
are valid even if they cannot be dereferenced yet. To avoid having to
make this distinction at build time, patches #3 and #4 replace such
valid references with RIP-relative references with an offset applied.
Patches #1 and #2 remove some absolute references from .head.text that
don't need to be there in the first place.
Questions:
- How can we police this at build time? Could we teach objtool to check
for absolute ELF relocations in .head.text, or does this belong in
modpost perhaps?
- Checking for absolute symbol references is not a complete solution, as
.head.text code could call into other code as well. Do we need rigid
checks for that too? Or could we have a soft rule that says you should
only call __head code from __head code?
Cc: Kevin Loughlin <kevinloughlin@...gle.com>
Cc: Tom Lendacky <thomas.lendacky@....com>
Cc: Dionna Glaze <dionnaglaze@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>
Cc: Kees Cook <keescook@...omium.org>
Cc: Brian Gerst <brgerst@...il.com>
Cc: linux-kernel@...r.kernel.org
Ard Biesheuvel (4):
x86/sev: Avoid WARN()s in early boot code
x86/xen/pvh: Move startup code into .ref.text
x86/boot/64: Determine VA/PA offset before entering C code
x86/boot/64: Avoid intentional absolute symbol references in
.head.text
arch/x86/include/asm/setup.h | 3 +-
arch/x86/kernel/head64.c | 38 ++++++++++++--------
arch/x86/kernel/head_64.S | 2 ++
arch/x86/kernel/sev.c | 15 +++-----
arch/x86/platform/pvh/head.S | 2 +-
5 files changed, 33 insertions(+), 27 deletions(-)
base-commit: 428080c9b19bfda37c478cd626dbd3851db1aff9
--
2.44.0.278.ge034bb2e1d-goog
Powered by blists - more mailing lists