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: <aLDo3F3KKW0MzlcH@google.com>
Date: Thu, 28 Aug 2025 16:40:12 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: 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, 
	"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 Wed, Aug 27, 2025, David Woodhouse wrote:
> On Tue, 2025-08-26 at 12:30 -0700, Sean Christopherson wrote:
> > 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.
> 
> And AMD's Secure TSC provides it in a GUEST_TSC_FREQ MSR, I believe.
> 
> For the non-CoCo cases, I do think we'd need at least that 'I pinky
> swear that CPUID 0x15 is telling the truth' bit — because right now, on
> today's hypervisors, I believe it might not be correct. So a guest
> can't trust it without that bit.
> 
> But I'm also concerned about the side-effects of advertising to guests
> that everything up to 0x15 is present, on older and AMD CPUs. 

Ah, you want to bolt this onto older vCPU models.  That makes sene.

> And I just don't see the point in that 'pinky swear' bit,

Yeah, I can see poorly written guest software freaking out over CPUID.0x15 being
unexpectedly valid, e.g. on AMD hardware, in which case pinky swearing it's ok
won't help.

> when there's an *existing* hypervisor leaf which just gives the information
> directly, which is implemented in QEMU and EC2, as well as various guests.

Can we just have the VMM do the work then?  I.e. carve out the bit and the
leaf in KVM's ABI, but leave it to the VMM to fill in?  I'd strongly prefer not
to hook kvm_cpuid(), as I don't like overriding userspace's CPUID entries, and
I especially don't like that hooking kvm_cpuid() means the value can change
throughout the lifetime of the VM, at least in theory, but in practice will only
ever be checked by the guest during early boot.