linux-kernel - Re: [PATCH 1/2] x86: cpu/bugs: add support for AMD ERAPS feature

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: <53c918b4-2e03-4f68-b3f3-d18f62d5805c@intel.com>
Date: Mon, 4 Nov 2024 08:26:44 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Shah, Amit" <Amit.Shah@....com>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "x86@...nel.org" <x86@...nel.org>
Cc: "corbet@....net" <corbet@....net>,
 "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
 "kai.huang@...el.com" <kai.huang@...el.com>,
 "pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
 "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
 "Lendacky, Thomas" <Thomas.Lendacky@....com>,
 "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>,
 "hpa@...or.com" <hpa@...or.com>, "peterz@...radead.org"
 <peterz@...radead.org>, "bp@...en8.de" <bp@...en8.de>,
 "Kaplan, David" <David.Kaplan@....com>
Subject: Re: [PATCH 1/2] x86: cpu/bugs: add support for AMD ERAPS feature

On 11/4/24 08:13, Shah, Amit wrote:
> I want to justify that not setting X86_FEATURE_RSB_CTXSW is still doing
> the right thing, albeit in hardware.

Let's back up a bit.

In the kernel, we have security concerns if RSB contents remain across
context switches.  If process A's RSB entries are left and then process
B uses them, there's a problem.

Today, we mitigate that issue with manual kernel RSB state zapping on
context switches (X86_FEATURE_RSB_CTXSW).

You're saying that this fancy new ERAPS feature includes a new mechanism
to zap RSB state.  But that only triggers "each time a TLB flush happens".

So what you're saying above is that you are concerned about RSB contents
sticking around across context switches.  But instead of using
X86_FEATURE_RSB_CTXSW, you believe that the new TLB-flush-triggered
ERAPS flush can be used instead.

Are we all on the same page so far?

I think you're wrong.  We can't depend on ERAPS for this.  Linux doesn't
flush the TLB on context switches when PCIDs are in play.  Thus, ERAPS
won't flush the RSB and will leave bad state in there and will leave the
system vulnerable.

Or what am I missing?