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: <aF1q-O_1FnNDLzWK@google.com>
Date: Thu, 26 Jun 2025 08:44:56 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.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, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 26, 2025 at 07:02:00AM -0700, Sean Christopherson wrote:
> > 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.

Yes, I know.

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

Maybe not _all_ the time.  But yes, I'm suggesting that QEMU clear ARCH_CAPABILITIES
when running on AMD.

> 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.

I don't think kvm-tool supports Windows, and I highly doubt any cloud provider
is doing the equivalent of QEMU's `-cpu host`.  I.e. I suspect QEMU is the only
VMM that's actually affected by this.

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

I have a hard time believing it'd be more complex.  More code, probably.  But
this isn't all that complex.