linux-kernel - Re: [RFC PATCH] x86/sev: x86/sev: enforce PC-relative addressing in clang

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: <CAGdbjmJcQeLWroBkbRC-cFQ6OuMHONsGLzpUrrA5k3uc8Rzkmw@mail.gmail.com>
Date: Wed, 10 Jan 2024 09:14:21 -0800
From: Kevin Loughlin <kevinloughlin@...gle.com>
To: Andi Kleen <ak@...ux.intel.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>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>, Kees Cook <keescook@...omium.org>, 
	"Masami Hiramatsu (Google)" <mhiramat@...nel.org>, Ze Gao <zegao2021@...il.com>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Pengfei Xu <pengfei.xu@...el.com>, 
	Brijesh Singh <brijesh.singh@....com>, Michael Roth <michael.roth@....com>, 
	Ashish Kalra <ashish.kalra@....com>, 
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Tom Lendacky <thomas.lendacky@....com>, 
	Joerg Roedel <jroedel@...e.de>, linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, 
	linux-coco@...ts.linux.dev, Adam Dunlap <acdunlap@...gle.com>, 
	Peter Gonda <pgonda@...gle.com>, Jacob Xu <jacobhxu@...gle.com>, 
	Sidharth Telang <sidtelang@...gle.com>
Subject: Re: [RFC PATCH] x86/sev: x86/sev: enforce PC-relative addressing in clang

On Wed, Jan 10, 2024 at 3:45 AM Andi Kleen <ak@...ux.intel.com> wrote:
>
> On Wed, Jan 10, 2024 at 01:26:39AM +0000, Kevin Loughlin wrote:
> >
> > While an attempt was made to force PC-relative addressing for certain
> > global SEV/SME variables via inline assembly (see snp_cpuid_get_table()
> > for example), PC-relative addressing must be pervasively-enforced for
> > SEV/SME global variables that can be accessed prior to page table
> > fixups.
> >
> > To avoid the error-prone approach of manually referencing each SEV/SME
> > global variable via a general form of snp_cpuid_get_table(), it is
> > preferable to use compiler flags for position-independent code (ex:
>
> But if gcc doesn't support it then it doesn't work.
>
> It seems your approach with incompatible execution models between
> the compilers is just a recipe for future patches only working
> on one of the compilers because most code submitters probably
> won't test both.
>
> It would be better to at least use a unified execution model, if you want
> to extend the hack and not fix the underlying issue.

Fair point; while gcc (unlike clang) appears to currently generate
PC-relative accesses to these vars, the patch in its current state
would not account for gcc's behavior potentially changing in the
future.

On that note, I do have another version of this patch that abstracts
snp_cpuid_get_table() into a macro along the lines of...

#define GET_RIP_RELATIVE_PTR(var) \
({  \
 void *ptr; \
 asm ("lea "#var"(%%rip), %0" \
      : "=r" (ptr) \
      : "p" (&var)); \
 ptr; \
})

..and uses this new macro to access all SEV/SME global variables (not
just the cpuid_table). It's similar in nature to `fixup_pointer()`
(currently defined in arch/x86/kernel/head64.c) but doesn't require us
to pass around `physaddr` from `__startup64()`. This wouldn't
introduce any new execution model changes between clang vs gcc and
would be consistent with the kernel's current approach of relying on
developers to manually apply fixups for global variable accesses prior
to kernel relocation. I can send an RFC v2 for the
GET_RIP_RELATIVE_PTR() version of this patch.