linux-kernel - Re: [PATCH] kvm/x86: ARCH_CAPABILITIES should not be advertised on AMD

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: <aF1ntuyr8gHleCwA@char.us.oracle.com>
Date: Thu, 26 Jun 2025 11:31:02 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Alexandre Chartre <alexandre.chartre@...cle.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org, pbonzini@...hat.com,
        xiaoyao.li@...el.com, x86@...nel.org, boris.ostrovsky@...cle.com,
        Jim Mattson <jmattson@...gle.com>
Subject: Re: [PATCH] kvm/x86: ARCH_CAPABILITIES should not be advertised on
 AMD

On Thu, Jun 26, 2025 at 07:02:00AM -0700, Sean Christopherson wrote:
> +Jim
> 
> For the scope, "KVM: x86:"
> 
> On Thu, Jun 26, 2025, Alexandre Chartre wrote:
> > KVM emulates the ARCH_CAPABILITIES on x86 for both vmx and svm.
> > However the IA32_ARCH_CAPABILITIES MSR is an Intel-specific MSR
> > so it makes no sense to emulate it on AMD.
> > 
> > The AMD documentation specifies that this MSR is not defined on
> > the AMD architecture. So emulating this MSR on AMD can even cause
> > issues (like Windows BSOD) as the guest OS might not expect this
> > MSR to exist on such architecture.
> > 
> > Signed-off-by: Alexandre Chartre <alexandre.chartre@...cle.com>
> > ---
> > 
> > A similar patch was submitted some years ago but it looks like it felt
> > through the cracks:
> > https://lore.kernel.org/kvm/20190307093143.77182-1-xiaoyao.li@linux.intel.com/
> 
> It didn't fall through the cracks, we deliberately elected to emulate the MSR in
> common code so that KVM's advertised CPUID support would match KVM's emulation.
> 
>   On Thu, 2019-03-07 at 19:15 +0100, Paolo Bonzini wrote:
>   > On 07/03/19 18:37, Sean Christopherson wrote:
>   > > On Thu, Mar 07, 2019 at 05:31:43PM +0800, Xiaoyao Li wrote:
>   > > > At present, we report F(ARCH_CAPABILITIES) for x86 arch(both vmx and svm)
>   > > > unconditionally, but we only emulate this MSR in vmx. It will cause #GP
>   > > > while guest kernel rdmsr(MSR_IA32_ARCH_CAPABILITIES) in an AMD host.
>   > > > 
>   > > > Since MSR IA32_ARCH_CAPABILITIES is an intel-specific MSR, it makes no
>   > > > sense to emulate it in svm. Thus this patch chooses to only emulate it
>   > > > for vmx, and moves the related handling to vmx related files.
>   > > 
>   > > What about emulating the MSR on an AMD host for testing purpsoes?  It
>   > > might be a useful way for someone without Intel hardware to test spectre
>   > > related flows.
>   > > 
>   > > In other words, an alternative to restricting emulation of the MSR to
>   > > Intel CPUS would be to move MSR_IA32_ARCH_CAPABILITIES handling into
>   > > kvm_{get,set}_msr_common().  Guest access to MSR_IA32_ARCH_CAPABILITIES
>   > > is gated by X86_FEATURE_ARCH_CAPABILITIES in the guest's CPUID, e.g.
>   > > RDMSR will naturally #GP fault if userspace passes through the host's
>   > > CPUID on a non-Intel system.
>   > 
>   > This is also better because it wouldn't change the guest ABI for AMD
>   > processors.  Dropping CPUID flags is generally not a good idea.
>   > 
>   > Paolo
> 
> I don't necessarily disagree about emulating ARCH_CAPABILITIES being pointless,
> but Paolo's point about not changing ABI for existing setups still stands.  This
> has been KVM's behavior for 6 years (since commit 0cf9135b773b ("KVM: x86: Emulate
> MSR_IA32_ARCH_CAPABILITIES on AMD hosts"); 7 years, if we go back to when KVM
> enumerated support without emulating the MSR (commit 1eaafe91a0df ("kvm: x86:
> IA32_ARCH_CAPABILITIES is always supported").
> 
> And it's not like KVM is forcing userspace to enumerate support for
> ARCH_CAPABILITIES, e.g. QEMU's named AMD configs don't enumerate support.  So
> while I completely agree KVM's behavior is odd and annoying for userspace to deal
> with, this is probably something that should be addressed in userspace.

If you do -cpu host we tack this on all the time.

Or you saying we should have QEMU disable this for AMD CPUs all the time?

Which in effect is the same thing as doing this patch.. but just moving
it to QEMU, kvm-tool, Google Cloud user-space thingie, AWS cloud thingie.

That is a lot more complexity than doing it in the kernel.

> 
> > I am resurecting this change because some recent Windows updates (like OS Build
> > 26100.4351) crashes on AMD KVM guests (BSOD with Stop code: UNSUPPORTED PROCESSOR)
> > just because the ARCH_CAPABILITIES is available.
> > 
> > ---
> >  arch/x86/kvm/svm/svm.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index ab9b947dbf4f..600d2029156e 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -5469,6 +5469,9 @@ static __init void svm_set_cpu_caps(void)
> >  
> >  	/* Don't advertise Bus Lock Detect to guest if SVM support is absent */
> >  	kvm_cpu_cap_clear(X86_FEATURE_BUS_LOCK_DETECT);
> > +
> > +	/* Don't advertise ARCH_CAPABILITIES on AMD */
> > +	kvm_cpu_cap_clear(X86_FEATURE_ARCH_CAPABILITIES);
> 
> Strictly speaking, I think we'd want to update svm_has_emulated_msr() as well.
> 
> >  }
> >  
> >  static __init int svm_hardware_setup(void)
> > -- 
> > 2.43.5
> > 
>