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: <CAMj1kXEbd5tNqqLaPxFTAFnx0S-o8Fftc0fvtQUHRN6d2zSk7w@mail.gmail.com>
Date: Wed, 17 Jan 2024 12:55:20 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Borislav Petkov <bp@...en8.de>, 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>, 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 12:39, Andi Kleen <ak@...ux.intel.com> wrote:
>
> On Wed, Jan 17, 2024 at 11:59:14AM +0100, Ard Biesheuvel wrote:
> > 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.
>
> For the SEV file this might not work because it also has functions
> that get called later at runtime, and may need to reference real
> globals. I doubt the linker could resolve that.
>

I don't think that should be a problem. If the code and data are
within -/+ 2G of each other, RIP-relative references should always be
in range.

> For linking the whole kernel, I haven't seen the latest numbers, but
> traditionally -fPIE/PIC cost some performance because globals get loaded
> through the GOT instead of directly as immediates. That's why the original
> x86-64 port went with -mcmodel=kernel.
>

We can tell the compiler to avoid the GOT (using 'hidden' visibility),
and even if we don't, the amd64 psABI now defines linker relaxations
that turn GOT loads into LEA instructions (which still bloat the code
a bit but eliminate the GOT accesses in most cases).