linux-kernel - Re: [PATCH v2 1/2] x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f43ebdd781d821d7fabdd85f1eebf8acd980566f.camel@amd.com>
Date: Mon, 2 Dec 2024 11:15:24 +0000
From: "Shah, Amit" <Amit.Shah@....com>
To: "jpoimboe@...nel.org" <jpoimboe@...nel.org>, "bp@...en8.de" <bp@...en8.de>
CC: "corbet@....net" <corbet@....net>, "pawan.kumar.gupta@...ux.intel.com"
	<pawan.kumar.gupta@...ux.intel.com>, "kai.huang@...el.com"
	<kai.huang@...el.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "Lendacky,
 Thomas" <Thomas.Lendacky@....com>, "daniel.sneddon@...ux.intel.com"
	<daniel.sneddon@...ux.intel.com>, "boris.ostrovsky@...cle.com"
	<boris.ostrovsky@...cle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "Moger,
 Babu" <Babu.Moger@....com>, "Das1, Sandipan" <Sandipan.Das@....com>,
	"dwmw@...zon.co.uk" <dwmw@...zon.co.uk>, "amit@...nel.org" <amit@...nel.org>,
	"hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org"
	<peterz@...radead.org>, "Kaplan, David" <David.Kaplan@....com>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v2 1/2] x86/bugs: Don't fill RSB on VMEXIT with
 eIBRS+retpoline

On Sat, 2024-11-30 at 16:31 +0100, Borislav Petkov wrote:
> On Thu, Nov 21, 2024 at 12:07:18PM -0800, Josh Poimboeuf wrote:
> > eIBRS protects against RSB underflow/poisoning attacks.  Adding
> > retpoline to the mix doesn't change that.  Retpoline has a balanced
> > CALL/RET anyway.
> 
> This is exactly why I've been wanting for us to document our
> mitigations for
> a long time now.

FWIW, I'd say we have fairly decent documentation with commit messages
+ code + comments in code.

> A bunch of statements above for which I can only rhyme up they're
> correct if
> I search for the vendor docs. On the AMD side I've found:

[...]

> In any case, I'd like for us to do have a piece of text accompanying
> such
> patches, perhaps here:
> 
> Documentation/admin-guide/hw-vuln/spectre.rst
> 
> which quotes the vendor docs.

If you're saying that we need *additional* documentation that
replicates hw manuals and the knowledge we have in our commit + code +
comments, that I agree with.

I got the feeling earlier, though, that you were saying we need that
documentation *instead of* the current comments-within-code, and that
didn't sound like the right thing to do.

> The current thread(s) on the matter already show how much confused we
> all are
> by all the possible mitigation options, uarch speculative dances etc
> etc.

... and the code flows and looks much better after this commit (for
SpectreRSB at least), which is a huge plus.

It's important to note that at some point in the past we got
vulnerabilities and hw features/quirks one after the other, and we kept
tacking mitigation code on top of the existing one -- because that's
what you need to do during an embargo period.  Now's the moment when
we're consolidating it all while taking stock of the overall situation.
This looks like a sound way to go about taking a higher-level view and
simplifying the code.

I doubt we'd want to do things any other way; and much less doing this
kind of an exercise during an embargo.  Moving comments out of the code
will only add to frustration during embargo periods.

Just my 2c

		Amit