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: <CAMj1kXH=k26nNyB+LQJ7WUJgbD2f3PREyjCzSngMCGc+72XJ6w@mail.gmail.com>
Date: Wed, 17 Jan 2024 11:59:14 +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 Mon, 15 Jan 2024 at 21:47, Borislav Petkov <bp@...en8.de> wrote:
>
> On Thu, Jan 11, 2024 at 10:36:50PM +0000, Kevin Loughlin wrote:
> > SEV/SME code can execute prior to page table fixups for kernel
> > relocation. However, as with global variables accessed in
> > __startup_64(), the compiler is not required to generate RIP-relative
> > accesses for SEV/SME global variables, causing certain flavors of SEV
> > hosts and guests built with clang to crash during boot.
>
> So, about that. If I understand my gcc toolchain folks correctly:
>
> mcmodel=kernel - everything fits into the high 31 bit of the address
> space
>
> -fPIE/PIC - position independent
>
> And supplied both don't make a whole lotta of sense: if you're building
> position-independent, then mcmodel=kernel would be overridden by the
> first.
>
> I have no clue why clang enabled it...
>
> So, *actually* the proper fix here should be not to add this "fixed_up"
> gunk everywhere but remove mcmodel=kernel from the build and simply do
> -fPIE/PIC.
>

Fully agree. All this fiddling with RIP relative references from C
code is going to be a maintenance burden going forward.

The proper way to do this is use PIC codegen for the objects that
matter. I had a stab [0] at this a while ago (for the purpose of
increasing the KASLR range, which requires PIE linking) but I didn't
pursue it in the end.

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)



[0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=x86-pie&id=4ba81de75d92fafdab2a8a389d1b7791dddf74f3