linux-kernel - [RFC PATCH v6.10 0/4] x86: Rid .head.text of all abs references

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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