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: <Z6JqopU5LkDIZPq6@google.com>
Date: Tue, 4 Feb 2025 11:29:38 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Nikunj A Dadhania <nikunj@....com>
Cc: 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, 
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Juergen Gross <jgross@...e.com>, 
	"K. Y. Srinivasan" <kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, 
	Dexuan Cui <decui@...rosoft.com>, Ajay Kaher <ajay.kaher@...adcom.com>, 
	Alexey Makhalov <alexey.amakhalov@...adcom.com>, Jan Kiszka <jan.kiszka@...mens.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, Andy Lutomirski <luto@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org, 
	linux-coco@...ts.linux.dev, virtualization@...ts.linux.dev, 
	linux-hyperv@...r.kernel.org, jailhouse-dev@...glegroups.com, 
	kvm@...r.kernel.org, xen-devel@...ts.xenproject.org, 
	Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH 06/16] x86/tdx: Override PV calibration routines with
 CPUID-based calibration

On Tue, Feb 04, 2025, Nikunj A Dadhania wrote:
> Sean Christopherson <seanjc@...gle.com> writes:
> 
> > When running as a TDX guest, explicitly override the TSC frequency
> > calibration routine with CPUID-based calibration instead of potentially
> > relying on a hypervisor-controlled PV routine.  For TDX guests, CPUID.0x15
> > is always emulated by the TDX-Module, i.e. the information from CPUID is
> > more trustworthy than the information provided by the hypervisor.
> >
> > To maintain backwards compatibility with TDX guest kernels that use native
> > calibration, and because it's the least awful option, retain
> > native_calibrate_tsc()'s stuffing of the local APIC bus period using the
> > core crystal frequency.  While it's entirely possible for the hypervisor
> > to emulate the APIC timer at a different frequency than the core crystal
> > frequency, the commonly accepted interpretation of Intel's SDM is that APIC
> > timer runs at the core crystal frequency when that latter is enumerated via
> > CPUID:
> >
> >   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).
> >
> > If the hypervisor is malicious and deliberately runs the APIC timer at the
> > wrong frequency, nothing would stop the hypervisor from modifying the
> > frequency at any time, i.e. attempting to manually calibrate the frequency
> > out of paranoia would be futile.
> >
> > Deliberately leave the CPU frequency calibration routine as is, since the
> > TDX-Module doesn't provide any guarantees with respect to CPUID.0x16.
> 
> Does TDX use kvmclock?

A TDX guest can.  That's up to the host (expose kvmclock) and the guest (enable
kvmclock).

> If yes, kvmclock would have registered the CPU frequency calibration routine:
> 
> 	tsc_register_calibration_routines(kvm_get_tsc_khz, kvm_get_cpu_khz,
>  					  tsc_properties);
> 
> so TDX will use kvm_get_cpu_khz(), which will either use CPUID.0x16 or
> PV clock, is this on the expected line ?

What do you mean by "is this on the expected line"?  If you are asking "is this
intended", then the answer is "yes, working as intended".  As above, the TDX-Module
doesn't emulate CPUID.0x16, so no matter what, the guest is relying on the untrusted
hypervisor to get the CPU frequency.  If someone thinks that TDX guests should
assume the CPU runs as the same frequency as the TSC, a la SNP's Secure TSC, then
they are welcome to propose such a change.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ