[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <97f499912538a81f06936ff02e8236bb01a82ae8.camel@amd.com>
Date: Tue, 5 Nov 2024 16:25:07 +0000
From: "Shah, Amit" <Amit.Shah@....com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "dave.hansen@...el.com"
<dave.hansen@...el.com>, "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 Tue, 2024-11-05 at 08:19 -0800, Dave Hansen wrote:
> On 11/5/24 02:39, Shah, Amit wrote:
> > On Mon, 2024-11-04 at 09:45 -0800, Dave Hansen wrote:
> > I'm expecting the APM update come out soon, but I have put together
> >
> > https://amitshah.net/2024/11/eraps-reduces-software-tax-for-hardware-bugs/
> >
> > based on information I have. I think it's mostly consistent with
> > what
> > I've said so far - with the exception of the mov-CR3 flush only
> > confirmed yesterday.
>
> That's better. But your original cover letter did say:
>
> Feature documented in AMD PPR 57238.
>
> which is technically true because the _bit_ is defined. But it's
> far,
> far from being sufficiently documented for Linux to actually use it.
Yea; apologies.
> Could we please be more careful about these in the future?
>
> > > So, I'll flip this back around. Today, X86_FEATURE_RSB_CTXSW
> > > zaps
> > > the
> > > RSB whenever RSP is updated to a new task stack. Please convince
> > > me
> > > that ERAPS provides superior coverage or is unnecessary in all
> > > the
> > > possible combinations switching between:
> > >
> > > different thread, same mm
> >
> > This case is the same userspace process with valid addresses in the
> > RSB
> > for that process. An invalid speculation isn't security sensitive,
> > just a misprediction that won't be retired. So we are good here.
>
> Does that match what the __switch_to_asm comment says, though?
>
> > /*
> > * When switching from a shallower to a deeper call stack
> > * the RSB may either underflow or use entries populated
> > * with userspace addresses. On CPUs where those concerns
> > * exist, overwrite the RSB with entries which capture
> > * speculative execution to prevent attack.
> > */
>
> It is also talking just about call depth, not about same-address-
> space
> RSB entries being harmless. That's because this is also trying to
> avoid
> having the kernel consume any user-placed RSB entries, regardless of
> whether they're from the same mm or not.
>
> > > user=>kernel, same mm
> > > kernel=>user, same mm
> >
> > user-kernel is protected with SMEP. Also, we don't call
> > FILL_RETURN_BUFFER for these switches?
>
> Amit, I'm beginning to fear that you haven't gone and looked at the
> relevant code here. Please go look at
> SYM_FUNC_START(__switch_to_asm)
> in arch/x86/entry/entry_64.S. I believe this code is called for all
> task switches, including switching from a user task to a kernel
> task. I
> also believe that FILL_RETURN_BUFFER is used unconditionally for
> every
> __switch_to_asm call (when X86_FEATURE_RSB_CTXSW is on of course).
>
> Could we please start over on this patch?
>
> Let's get the ERAPS+TLB-flush nonsense out of the kernel and get the
> commit message right.
>
> Then let's go from there.
Alright - you've been really patient, so thanks for that. I agree I'll
post a v2 with updated commit messages, and then continue this
discussion on user/kernel task switch. And I'll also add an RFC tag to
it to ensure it doesn't get picked up.
Amit
Powered by blists - more mailing lists