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: <6783241f1bfadad8429f66c82a2f8810a74285a0.camel@infradead.org>
Date: Thu, 21 Aug 2025 21:42:18 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: 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,
 "H. Peter Anvin" <hpa@...or.com>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 kvm@...r.kernel.org, linux-kernel@...r.kernel.org,  graf@...zon.de, Ajay
 Kaher <ajay.kaher@...adcom.com>, Alexey Makhalov
 <alexey.makhalov@...adcom.com>, Colin Percival <cperciva@...snap.com>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
 and host

On Thu, 2025-08-21 at 12:27 -0700, Sean Christopherson wrote:
>  
> > The problem with that is that it's been quite unreliable. The kernel
> > doesn't trust it even on chips as recent (hah) as Skylake. I'd be
> > happier to trust what the hypervisor explicitly gives us. But yes, it
> > should be *one* of the sources of information before we reverse-
> > calculate it from the pvclock. 
> 
> Sorry, by "the VMM use" I mean have the host, e.g. QEMU, explicitly define TSC
> frequency in CPUID.0x15 and CPU frequency in CPUID.0x16.  And then on the
> KVM-as-a-guest side of things, trust those leaves when they're available.

Those leaves are untrustworthy on hardware. Are you suggesting that the
kernel should trust them when it detects that it's running under KVM,
on the assumption that KVM will have corrected them? And that KVM will
be fabricating them even on CPU models which didn't naturally have
those leaves? And that in the presence of TSC scaling, those leaves
will show the right values for the guest even on hypervisors running
today?

I'll be surprised if that works out well.

I think I'm a lot happier with the explicit CPUID leaf exposed by the
hypervisor.

> So same idea as having the VMM fill 0x4000_0010, but piggyback the Intel-defined
> leaves instead of the VMware-defined leaf.  One of the reasons I'd like to go
> that route is to avoid having to choose one or the other when running under TDX,
> where CPUID.{0x15,0x16} are provided by the "trusted" TDX-Module, but any PV
> leaf is not.
> 
> Dunno how feasible it is to get non-Linux guests on board though...

FreeBSD as a guest already uses 0x4000_0010, and QEMU already supports
exposing it with the vmware-cpuid-freq option.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)