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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 7 Mar 2024 15:42:24 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: 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: Re: [RFC PATCH v6.10 0/4] x86: Rid .head.text of all abs references

(remove bogus 'linux-kernel@...gle.com' from the To: line)

On Thu, 7 Mar 2024 at 15:30, Ard Biesheuvel <ardb+git@...gle.com> wrote:
>
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ