Re: [PATCH v3 2/6] x86/bugs: Use SBPB in __write_ibpb() if applicable

[Jim Mattson]

On Wed, Apr 9, 2025 at 11:29 AM Kaplan, David <David.Kaplan@xxxxxxx> wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Jim Mattson <jmattson@xxxxxxxxxx>
> > Sent: Wednesday, April 9, 2025 11:07 AM
> > To: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> > Cc: x86@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; amit@xxxxxxxxxx;
> > kvm@xxxxxxxxxxxxxxx; Shah, Amit <Amit.Shah@xxxxxxx>; Lendacky, Thomas
> > <Thomas.Lendacky@xxxxxxx>; bp@xxxxxxxxx; tglx@xxxxxxxxxxxxx;
> > peterz@xxxxxxxxxxxxx; pawan.kumar.gupta@xxxxxxxxxxxxxxx; corbet@xxxxxxx;
> > mingo@xxxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; hpa@xxxxxxxxx;
> > seanjc@xxxxxxxxxx; pbonzini@xxxxxxxxxx; daniel.sneddon@xxxxxxxxxxxxxxx;
> > kai.huang@xxxxxxxxx; Das1, Sandipan <Sandipan.Das@xxxxxxx>;
> > boris.ostrovsky@xxxxxxxxxx; Moger, Babu <Babu.Moger@xxxxxxx>; Kaplan,
> > David <David.Kaplan@xxxxxxx>; dwmw@xxxxxxxxxxxx;
> > andrew.cooper3@xxxxxxxxxx
> > Subject: Re: [PATCH v3 2/6] x86/bugs: Use SBPB in __write_ibpb() if applicable
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Apr 2, 2025 at 7:18 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Apr 02, 2025 at 02:04:04PM -0700, Jim Mattson wrote:
> > > > On Wed, Apr 2, 2025 at 11:20 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> > wrote:
> > > > >
> > > > > __write_ibpb() does IBPB, which (among other things) flushes
> > > > > branch type predictions on AMD.  If the CPU has SRSO_NO, or if the
> > > > > SRSO mitigation has been disabled, branch type flushing isn't
> > > > > needed, in which case the lighter-weight SBPB can be used.
> > > >
> > > > When nested SVM is not supported, should KVM "promote"
> > > > SRSO_USER_KERNEL_NO on the host to SRSO_NO in
> > KVM_GET_SUPPORTED_CPUID?
> > > > Or is a Linux guest clever enough to do the promotion itself if
> > > > CPUID.80000001H:ECX.SVM[bit 2] is clear?
> > >
> > > I'm afraid that question is beyond my pay grade, maybe some AMD or
> > > virt folks can chime in.
> >
> > That question aside, I'm not sure that this series is safe with respect to nested
> > virtualization.
> >
> > If the CPU has SRSO_NO, then KVM will report SRSO_NO in
> > KVM_GET_SUPPORTED_CPUID. However, in nested virtualization, the L1 guest
> > and the L2 guest share a prediction domain. KVM currently ensures isolation
> > between L1 and L2 with a call to
> > indirect_branch_prediction_barrier() in svm_vcpu_load(). I think that particular
> > barrier should *always* be a full IBPB--even if the host has SRSO_NO.
>
> I don't think that's true.
>
> If SRSO_NO=1, the indirect_branch_prediction_barrier() in svm_vcpu_load() I believe only needs to prevent indirect predictions from leaking from one VM to another, which is what SBPB provides.  Keep in mind that before SRSO came out, IBPB on these parts was only flushing indirect predictions.  SBPB become the 'legacy' IBPB functionality while IBPB turned into a full flush (on certain parts).  If the CPU is immune to SRSO, you don't need the full flush.
>
> I also don't think promoting SRSO_USER_KERNEL_NO to SRSO_NO should ever be done.  When SRSO_NO=1, it tells the OS that it can use SBPB on context switches because the only process->process BTB concern is with indirect predictions.  The OS has to use IBPB if SRSO_NO=0 (regardless of SRSO_USER_KERNEL_NO) to prevent SRSO attacks from process->process.

Thanks, David!

Conceptually, it sounds like SRSO_NO = (SRSO_USER_KERNEL_NO +
SRSO_SAME_MODE_NO). You don't need an IBPB between L1 and L2 on
SRSO_NO parts, because SRSO_SAME_MODE_NO is implied. Similarly, you
can't "promote" SRSO_USER_KERNEL_NO to SRSO_NO, even absent SVM,
because SRSO_SAME_MODE_NO is missing.