linux-kernel - Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALMp9eTwao7qWsmVTDgqW_KdjMKeRBYp1JpfN2Xyj+qVyLwHbA@mail.gmail.com>
Date: Wed, 8 Jan 2025 10:37:57 -0800
From: Jim Mattson <jmattson@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Sean Christopherson <seanjc@...gle.com>, Borislav Petkov <bp@...nel.org>, X86 ML <x86@...nel.org>, 
	Paolo Bonzini <pbonzini@...hat.com>, Josh Poimboeuf <jpoimboe@...hat.com>, 
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, KVM <kvm@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR_FIX

On Wed, Jan 8, 2025 at 10:15 AM Borislav Petkov <bp@...en8.de> 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
>