Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR_FIX

[Jim Mattson]

On Wed, Jan 8, 2025 at 10:15 AM Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Wed, Jan 08, 2025 at 09:18:17AM -0800, Sean Christopherson wrote:
> > then my vote is to go with the user_return approach.  It's unfortunate that
> > restoring full speculation may be delayed until a CPU exits to userspace or KVM
> > is unloaded, but given that enable_virt_at_load is enabled by default, in practice
> > it's likely still far better than effectively always running the host with reduced
> > speculation.
>
> I guess. Kaplan just said something to that effect so I guess we can start
> with that and then see who complains and address it if she cries loud enough.
> :-P
>
> > No?  svm_vcpu_load() emits IBPB when switching VMCBs, i.e. when switching between
>
> Bah, nevermind. I got confused by our own whitepaper. /facepalm.
>
> So here's the deal:
>
> The machine has SRSO_USER_KERNEL_NO=1. Which means, you don't need safe-RET.
> So we fallback to ibpb-on-vmexit.

Surely, IBPB-on-VMexit is worse for performance than safe-RET?!?

(But, maybe I have a warped perspective, since I only care about VM
performance).

> Now, if the machine sports BpSpecReduce, we do that and that covers all the
> vectors. Otherwise, IBPB-on-VMEXIT it is.
>
> The VM/VM attack vector the paper is talking about and having to IBPB is for
> the Spectre v2 side of things. Not SRSO.
>
> Yeah, lemme document that while it is fresh in my head. This is exactly why
> I wanted Josh to start mitigation documentation - exactly for such nasties.
>
> Thx.
>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
>