Received-SPF: pass (google.com: domain of linux-kernel+bounces-95757-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240307143027.206179-6-ardb+git@google.com>
In-Reply-To: <20240307143027.206179-6-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Thu, 7 Mar 2024 15:42:24 +0100
Message-ID: <CAMj1kXG8jYmdvwz7dd-23Gispcy0Eia0gA+155Jy7=qOdd7Fwg@mail.gmail.com>
Subject: Re: [RFC PATCH v6.10 0/4] x86: Rid .head.text of all abs references
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Kevin Loughlin <kevinloughlin@google.com>, Tom Lendacky <thomas.lendacky@amd.com>, 
	Dionna Glaze <dionnaglaze@google.com>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, 
	Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>, Brian Gerst <brgerst@gmail.com>, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"

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

On Thu, 7 Mar 2024 at 15:30, Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.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@google.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Dionna Glaze <dionnaglaze@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Brian Gerst <brgerst@gmail.com>
> Cc: linux-kernel@vger.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
>