Re: [RFC PATCH v2] x86/sev: enforce RIP-relative accesses in early SEV/SME code

From: Ard Biesheuvel
Date: Wed Jan 17 2024 - 08:38:59 EST


On Wed, 17 Jan 2024 at 14:06, Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Wed, Jan 17, 2024 at 11:59:14AM +0100, Ard Biesheuvel wrote:
..
> > On arm64, we use a separate pseudo-namespace for code that can run
> > safely at any offset, using the __pi_ prefix (for Position
> > Independent). Using symbol prefixing at the linker level, we ensure
> > that __pi_ code can only call other __pi_ code, or code that has been
> > made available to it via an explicit __pi_ prefixed alias. (Happy to
> > elaborate more but we should find a smaller audience - your cc list is
> > a tad long). Perhaps this is something we should explore on x86 as
> > well (note that the EFI stub does something similar for architectures
> > that link the EFI stub into the core kernel rather than into the
> > decompressor)
>
> Grepping through the tree, is __pi_memcpy one example for that?
>

That is an example of a function that is known to be callable from any
context, and so it is emitted with an alias that makes it accessible
to other code that is position independent.

There is some linker foo in arch/arm64/kernel/pi/Makefile that builds
a couple of objects in PIC mode. The source symbols have ordinary
names (even the external imports), but will be renamed by the linker
to have a __pi_ prefix. The result is that those objects can only call
into each other, or out to ordinary code that has been marked as __pi_
as well.

The entry into this code is

arch/arm64/kernel/head.S:885: bl __pi_kaslr_early_init

which is called before relocations have been applied, as that requires
knowing how the kernel base address is randomized.