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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEML99u7a8mZMhiWXXozsJYhVPaaTzYkegiSJcLw2pNJg@mail.gmail.com>
Date: Wed, 17 Jan 2024 14:38:34 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Kevin Loughlin <kevinloughlin@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nick Desaulniers <ndesaulniers@...gle.com>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
	Tom Lendacky <thomas.lendacky@....com>, Michael Kelley <mikelley@...rosoft.com>, 
	Pankaj Gupta <pankaj.gupta@....com>, Stephen Rothwell <sfr@...b.auug.org.au>, 
	Arnd Bergmann <arnd@...db.de>, Steve Rutherford <srutherford@...gle.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, 
	Hou Wenlong <houwenlong.hwl@...group.com>, Vegard Nossum <vegard.nossum@...cle.com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Yuntao Wang <ytcoode@...il.com>, 
	Wang Jinchao <wangjinchao@...sion.com>, David Woodhouse <dwmw@...zon.co.uk>, 
	Brian Gerst <brgerst@...il.com>, Hugh Dickins <hughd@...gle.com>, Joerg Roedel <jroedel@...e.de>, 
	Randy Dunlap <rdunlap@...radead.org>, Bjorn Helgaas <bhelgaas@...gle.com>, 
	Dionna Glaze <dionnaglaze@...gle.com>, Brijesh Singh <brijesh.singh@....com>, 
	Michael Roth <michael.roth@....com>, 
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev, linux-coco@...ts.linux.dev, 
	Ashish Kalra <ashish.kalra@....com>, Andi Kleen <ak@...ux.intel.com>, 
	Adam Dunlap <acdunlap@...gle.com>, Peter Gonda <pgonda@...gle.com>, Jacob Xu <jacobhxu@...gle.com>, 
	Sidharth Telang <sidtelang@...gle.com>
Subject: Re: [RFC PATCH v2] x86/sev: enforce RIP-relative accesses in early
 SEV/SME code

On Wed, 17 Jan 2024 at 14:06, Borislav Petkov <bp@...en8.de> 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.