linux-kernel - Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest and host

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: <aLIPPxLt0acZJxYF@google.com>
Date: Fri, 29 Aug 2025 13:36:15 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Paul Durrant <pdurrant@...zon.co.uk>, Fred Griffoul <fgriffo@...zon.co.uk>, 
	Colin Percival <cperciva@...snap.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, Vitaly Kuznetsov <vkuznets@...hat.com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Graf (AWS), Alexander" <graf@...zon.de>, 
	Ajay Kaher <ajay.kaher@...adcom.com>, Alexey Makhalov <alexey.makhalov@...adcom.com>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
 and host

On Fri, Aug 29, 2025, David Woodhouse wrote:
> On Fri, 2025-08-29 at 11:08 +0000, Durrant, Paul wrote:
> > On 29/08/2025, 10:51, "David Woodhouse" <dwmw2@...radead.org <mailto:dwmw2@...radead.org>> wrote:
> > [snip]
> > > • Declare that we don't care that it's strictly an ABI change, and
> > > VMMs which used to just populate the leaf and let KVM fill it in
> > > for Xen guests now *have* to use the new API.
> > > 
> > > 
> > > I'm actually OK with that, even the last one, because I've just noticed
> > > that KVM is updating the *wrong* Xen leaf. 0x40000x03/2 EAX is supposed
> > > to be the *host* TSC frequency, and the guest frequency is supposed to
> > > be in 0x40000x03/0 ECX. And Linux as a Xen guest doesn't even use it
> > > anyway, AFAICT
> > > 
> > > Paul, it was your code originally; are you happy with removing it?
> > 
> > Yes, if it is incorrect then please fix it. I must have become
> > confused whilst reading the original Xen code. 
> 
> The proposal is not to *fix* it but just to rip it out entirely and
> provide userspace with some way of knowing the effective TSC frequency.
> 
> This does mean userspace would have to set the vCPU's TSC frequency and
> then query the kernel before setting up its CPUID. And in the absence
> of scaling, this KVM API would report the hardware TSC frequency.

Reporting the hardware TSC frequency on CPUs without scaling seems all kinds of
wrong (which another reason I don't like KVM shoving in the state).  Of course,
reporting the frequency KVM is trying to provide isn't great either, as the guest
will definitely observe something in between those two. 

> I guess the API would have to return -EHARDWARETOOSTUPID if the TSC frequency
> *isn't* the same across all CPUs and all power states, etc.

What if KVM advertises the flag in KVM_GET_SUPPORTED_CPUID if and only if the
TSC will be constant from the guest's perspective?  TSC scaling has been supported
by AMD and Intel for ~10 years, it doesn't seem at all unreasonable to restrict
the feature to somewhat modern hardware.  And if userspace or the admin knows
better than KVM, then userspace can always ignore KVM and report the frequency
anyways.