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] [day] [month] [year] [list]

Message-ID: <20241217093434.GAZ2FFqiC_pFimdoYu@fat_crate.local>
Date: Tue, 17 Dec 2024 10:34:34 +0100
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: 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 Mon, Dec 16, 2024 at 10:51:13AM -0800, Sean Christopherson wrote:
> but I don't see any code that would clear X86_FEATURE_SRSO_MSR_FIX.  Am I missing
> something?

Ah, you want the toggles in svm_{enable,disable}_virtualization_cpu() to not
happen when the mitigation is disabled. Yeah, I guess we should clear the flag
when the mitigation is disabled...

> Gah, sorry.  I suspect I got thinking about how best to "set it only when really
> needed", and got lost in analysis paralysis.

I know *exactly* what you're talking about :-P

> To some extent.  But I strongly suspect that the vast, vast majority of end users
> will end up with systems that automatically load kvm.ko, but don't run VMs the
> majority of the time.  Expecting non-KVM to users to detect a 1-2% regression and
> track down enable_virt_at_load doesn't seem like a winning strategy.

Yap, that was my fear too.  Frankly, I don't have a really good answer to
that yet.

> The other possibility would be to wait to set the bit until a CPU is actually
> going to do VMRUN.  If we use KVM's "user-return MSR" framework, the bit would
> be cleared when the CPU returns to userspace.  The only downside to that is KVM
> would toggle the bit on CPUs running vCPUs on every exit to userspace, e.g. to
> emulate MMIO/IO and other things.
> 
> But, userspace exits are relatively slow paths, so if the below is a wash for
> performance when running VMs, i.e. the cost of the WRMSRs is either in the noise
> or is offset by the regained 1-2% performance for userspace, then I think it's a
> no-brainer.
> 
> Enabling "full" speculation on return to usersepace means non-KVM tasks won't be
> affected, and there's no "sticky" behavior.  E.g. another idea would be to defer
> setting the bit until VMRUN is imminent, but then wait to clear the bit until
> virtualization is disabled.  But that has the downside of the bit being set on all
> CPUs over time, especially if enable_virt_at_load is true.

Yeah, I think we should keep it simple initially and only do anything more
involved when it turns out that we really need it.

> Compile tested only...

Thanks, looks good, I'll run it after I get back from vacation to make sure
we're good and then we'll talk again. :)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette