[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXG8jYmdvwz7dd-23Gispcy0Eia0gA+155Jy7=qOdd7Fwg@mail.gmail.com>
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