linux-kernel - Re: [PATCH v3 1/2] x86: KVM: Advertise FSRS and FSRC on AMD to userspace

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: <Z_kzFLUwN714lqk1@google.com>
Date: Fri, 11 Apr 2025 08:19:48 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Maksim Davydov <davydov-max@...dex-team.ru>, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, x86@...nel.org, babu.moger@....com, 
	mingo@...hat.com, tglx@...utronix.de, dave.hansen@...ux.intel.com, 
	hpa@...or.com, jmattson@...gle.com, pbonzini@...hat.com
Subject: Re: [PATCH v3 1/2] x86: KVM: Advertise FSRS and FSRC on AMD to userspace

On Fri, Apr 11, 2025, Borislav Petkov wrote:
> On Fri, Apr 11, 2025 at 06:49:54AM -0700, Sean Christopherson wrote:
> > KVM should still explicitly advertise support for AMD's flavor.  There are KVM
> > use cases where KVM's advertised CPUID support is used almost verbatim, in which
> 
> So that means the vendor differentiation is done by the user

Yes.

> and KVM shouldn't even try to unify things...?

Yeah, more or less.  KVM doesn't ever unify CPUID features, in the sense of giving
userspace one way to query support.

For better or worse, KVM does stuff feature bits for various mitigations, e.g. so
that kernels looking for just one or the other will get the desired behavior.

	if (boot_cpu_has(X86_FEATURE_AMD_IBPB_RET) &&
	    boot_cpu_has(X86_FEATURE_AMD_IBPB) &&
	    boot_cpu_has(X86_FEATURE_AMD_IBRS))
		kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL);
	if (boot_cpu_has(X86_FEATURE_STIBP))
		kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP);
	if (boot_cpu_has(X86_FEATURE_AMD_SSBD))
		kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD);

	...

	if (boot_cpu_has(X86_FEATURE_IBPB)) {
		kvm_cpu_cap_set(X86_FEATURE_AMD_IBPB);
		if (boot_cpu_has(X86_FEATURE_SPEC_CTRL) &&
		    !boot_cpu_has_bug(X86_BUG_EIBRS_PBRSB))
			kvm_cpu_cap_set(X86_FEATURE_AMD_IBPB_RET);
	}
	if (boot_cpu_has(X86_FEATURE_IBRS))
		kvm_cpu_cap_set(X86_FEATURE_AMD_IBRS);
	if (boot_cpu_has(X86_FEATURE_STIBP))
		kvm_cpu_cap_set(X86_FEATURE_AMD_STIBP);
	if (boot_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD))
		kvm_cpu_cap_set(X86_FEATURE_AMD_SSBD);
	if (!boot_cpu_has_bug(X86_BUG_SPEC_STORE_BYPASS))
		kvm_cpu_cap_set(X86_FEATURE_AMD_SSB_NO);
	/*
	 * The preference is to use SPEC CTRL MSR instead of the
	 * VIRT_SPEC MSR.
	 */
	if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) &&
	    !boot_cpu_has(X86_FEATURE_AMD_SSBD))
		kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD);

But we've generally agreed that KVM shouldn't do that going forward, because many
of the mitigations don't have strict 1:1 mappings between Intel and AMD, i.e.
deciding which bits to stuff gets dangerously close to defining policy, which KVM
definitely wants to stay away from.

> But I guess KVM isn't exporting CPUID *names* but CPUID *leafs* so the
> internal naming doesn't matter.

Yep, exactly.