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: <aK4LamiDBhKb-Nm_@google.com>
Date: Tue, 26 Aug 2025 12:30:50 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Colin Percival <cperciva@...snap.com>
Cc: David Woodhouse <dwmw2@...radead.org>, 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>
Subject: Re: [PATCH v2 0/3] Support "generic" CPUID timing leaf as KVM guest
 and host

On Fri, Aug 22, 2025, Colin Percival wrote:
> On 8/21/25 14:10, David Woodhouse wrote:
> > On Thu, 2025-08-21 at 13:48 -0700, Sean Christopherson wrote:
> > > > I think I'm a lot happier with the explicit CPUID leaf exposed by the
> > > > hypervisor.
> > > 
> > > Why?  If the hypervisor is ultimately the one defining the state, why does it
> > > matter which CPUID leaf its in?
> > [...]
> > 
> > If you tell me that 0x15 is *never* wrong when seen by a KVM guest, and
> > that it's OK to extend the hardware CPUID support up to 0x15 even on
> > older CPUs and there'll never be any adverse consequences from weird
> > assumptions in guest operating systems if we do the latter... well, for
> > a start, I won't believe you. And even if I do, I won't think it's
> > worth the risk. Just use a hypervisor leaf :)

But for CoCo VMs (TDX in particular), using a hypervisor leaf is objectively worse,
because the hypervisor leaf is emulated by the untrusted world, whereas CPUID.0x15
is emulated by the trusted world (TDX-Module).

If the issue is one of trust, what if we carve out a KVM_FEATURE_xxx bit that
userspace can set to pinky swear it isn't broken?

> FreeBSD developer here.  I'm with David on this, we'll consult the 0x15/0x16
> CPUID leaves if we don't have anything better, but I'm not going to trust
> those nearly as much as the 0x40000010 leaf.
> 
> Also, the 0x40000010 leaf provides the lapic frequency, which AFAIK is not
> exposed in any other way.

On Intel CPUs, CPUID.0x15 defines the APIC timer frequency:

  The APIC timer frequency will be the processor’s bus clock or core crystal clock
  frequency (when TSC/core crystal clock ratio is enumerated in CPUID leaf 0x15)
  divided by the value specified in the divide configuration register.

Thanks to TDX (again), that is also now KVM's ABI.