[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230822215901.nkikxpcmlrssi42l@treble>
Date: Tue, 22 Aug 2023 14:59:01 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Babu Moger <babu.moger@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Sean Christopherson <seanjc@...gle.com>, David.Kaplan@....com,
Andrew Cooper <andrew.cooper3@...rix.com>,
Nikolay Borisov <nik.borisov@...e.com>,
gregkh@...uxfoundation.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 04/22] x86/srso: Fix SBPB enablement for
spec_rstack_overflow=off
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.
--
Josh
Powered by blists - more mailing lists