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

Message-ID: <aLmTXb6PO02idqeM@google.com>
Date: Thu, 4 Sep 2025 06:25:49 -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 Thu, Sep 04, 2025, David Woodhouse wrote:
> On Thu, 2025-09-04 at 04:59 -0700, Sean Christopherson wrote:
> > 
> > I thought the original problem being solved was that the _guest_ doesn't know the
> > effective TSC frequency?  Userspace can already get the effectively TSC frequency
> > via KVM_GET_TSC_KHZ, why do we need another uAPI to provide that?  (Honest question,
> > I feel like I'm missing something)
> 
> I believe that KVM_GET_TSC_KHZ returns what userspace *asked* for the
> TSC frequency to be (vcpu->arch.virtual_tsc_khz), not what it actually
> ended up being based on the measured host frequency and the available
> scaling granularity (vcpu->hw_tsc_khz).

Ah, I see where you're coming from.  Purely out of curiosity, have you done the
math to see if slop would be a problem in practice?  No worries if you haven't,
just genuinely (and lazily) curious.

Anyways, I'm a-ok reporting that information in KVM_GET_SUPPORTED_CPUID (again,
only with constant TSC and scaling).  Reporting the effective frequency would be
useful for the host too, e.g. for sanity checks.  What I specifically want to
avoid is modifying guest CPUID at runtime.

Hmm, the only wrinkle is that, if there is slop, KVM could report different
information when run on different platforms, e.g. after live migration.  But so
long as that possibility is documented, I don't think it's truly problematic.
And it's another argument for not modifying guest CPUID directly; I'd rather let
userspace figure out whether or not they care about the divergence than silently
change things from the guest's perspective.

Alternatively (or in addition to), part of me wants to stealtily update
KVM_GET_TSC_KHZ to report back the effective frequency, but I can see that being
problematic, e.g. if a naive VMM reads KVM_GET_TSC_KHZ when saving vCPU state for
live migration and after enough migrations, the slop ends up drastically skewing
the guest's frequency.