[04/22] x86/srso: Fix SBPB enablement for spec_rstack_overflow=off

Message ID 23a121e309d5e880eb35c441d9bdfa642d6d59f4.1692580085.git.jpoimboe@kernel.org
State New
Headers
Series SRSO fixes/cleanups |

Commit Message

Josh Poimboeuf Aug. 21, 2023, 1:19 a.m. UTC
  If the user has requested no SRSO mitigation, other mitigations can use
the lighter-weight SBPB instead of IBPB.

Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 arch/x86/kernel/cpu/bugs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

Josh Poimboeuf Aug. 21, 2023, 4:36 p.m. UTC | #1
On Mon, Aug 21, 2023 at 04:16:19PM +0200, Borislav Petkov wrote:
> On Sun, Aug 20, 2023 at 06:19:01PM -0700, Josh Poimboeuf wrote:
> > If the user has requested no SRSO mitigation, other mitigations can use
> > the lighter-weight SBPB instead of IBPB.
> > 
> > Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
> > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > ---
> >  arch/x86/kernel/cpu/bugs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index b0ae985aa6a4..10499bcd4e39 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -2433,7 +2433,7 @@ static void __init srso_select_mitigation(void)
> >  
> >  	switch (srso_cmd) {
> >  	case SRSO_CMD_OFF:
> > -		return;
> > +		goto pred_cmd;
> 
> Can't do that - you need to synchronize it with retbleed. If retbleed
> has selected IBPB mitigation you must not override it.

Hm?  How exactly is this overriding the retbleed IBPB mitigation?
  
Josh Poimboeuf Aug. 22, 2023, 9:59 p.m. UTC | #2
On Tue, Aug 22, 2023 at 08:07:06AM +0200, Borislav Petkov wrote:
> On Tue, Aug 22, 2023 at 07:54:52AM +0200, Borislav Petkov wrote:
> > If you goto pred_cmd, you will overwrite it with PRED_CMD_SBPB here.
> 
> Looking at this more:
> 
> "If SRSO mitigation is not required or is disabled, software may use
> SBPB on context/virtual machine switch to help protect against
> vulnerabilities like Spectre v2."
> 
> I think we actually want this overwrite to happen.

Yeah, I had seen that.  The combination of spectre_v2_user=on with
srso=off doesn't make a whole lot of sense, but... give the user what
they want and all.  Which would presumably be IBPB *without* the SRSO
mitigation (aka SBPB).

> But then if retbleed=ibpb, entry_ibpb() will do bit 0 unconditionally...
> 
> Hmm, lemme talk to people.

I don't think we need to worry about that, SBPB is >= fam19 but retbleed
is <= fam17.  So either way (0x17 or 0x19) entry_ibpb() should do IBPB.
  

Patch

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index b0ae985aa6a4..10499bcd4e39 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -2433,7 +2433,7 @@  static void __init srso_select_mitigation(void)
 
 	switch (srso_cmd) {
 	case SRSO_CMD_OFF:
-		return;
+		goto pred_cmd;
 
 	case SRSO_CMD_MICROCODE:
 		if (has_microcode) {