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]

Date: Fri, 12 Jan 2024 15:17:25 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Kevin Loughlin <kevinloughlin@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	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>,
	Ard Biesheuvel <ardb@...nel.org>, 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>, 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 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.
> 
> While an attempt was made to force RIP-relative addressing for certain
> global SEV/SME variables via inline assembly (see snp_cpuid_get_table()
> for example), RIP-relative addressing must be pervasively-enforced for
> SEV/SME global variables when accessed prior to page table fixups.
> 
> __startup_64() already handles this issue for select non-SEV/SME global
> variables using fixup_pointer(), which adjusts the pointer relative to
> a `physaddr` argument. To avoid having to pass around this `physaddr`
> argument across all functions needing to apply pointer fixups, this
> patch introduces the macro GET_RIP_RELATIVE_PTR() (an abstraction of
> the existing snp_cpuid_get_table()), which generates an RIP-relative
> pointer to a passed variable. Similarly, PTR_TO_RIP_RELATIVE_PTR() is
> introduced to fixup an existing pointer value with RIP-relative logic.

Can we replace existing fixup_pointer() (and other fixup_*()) with the new
thing? I don't think we need two confusing things for the same function.

Also, is there any reason why GET_RIP_RELATIVE_PTR() and
PTR_TO_RIP_RELATIVE_PTR() have to be macros? Inline functions would be
cleaner.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov