| Message ID | 20250201021718.699411-1-seanjc@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | x86/tsc: Try to wrangle PV clocks vs. TSC | expand |
On Fri, Jan 31, 2025 at 06:17:02PM -0800, Sean Christopherson wrote: > And if the host provides the core crystal frequency in CPUID.0x15, then KVM > guests can use that for the APIC timer period instead of manually > calibrating the frequency. Hmm, so that part: what's stopping the host from faking the CPUID leaf? I.e., I would think that actually doing the work to calibrate the frequency would be more reliable/harder to fake to a guest than the guest simply reading some untrusted values from CPUID... Or are we saying here: oh well, there are so many ways for a normal guest to be lied to so that we simply do the completely different approach and trust the HV to be benevolent when we're not dealing with confidential guests which have all those other things to keep the HV honest? Just checking the general thinking here. Thx.
On Tue, Feb 11, 2025, Borislav Petkov wrote: > On Fri, Jan 31, 2025 at 06:17:02PM -0800, Sean Christopherson wrote: > > And if the host provides the core crystal frequency in CPUID.0x15, then KVM > > guests can use that for the APIC timer period instead of manually > > calibrating the frequency. > > Hmm, so that part: what's stopping the host from faking the CPUID leaf? I.e., > I would think that actually doing the work to calibrate the frequency would be > more reliable/harder to fake to a guest than the guest simply reading some > untrusted values from CPUID... Not really. Crafting an attack based on timing would be far more difficult than tricking the guest into thinking the APIC runs at the "wrong" frequency. The APIC timer itself is controlled by the hypervisor, e.g. the host can emulate the timer at the "wrong" freuquency on-demand. Detecting that the guest is post-boot and thus done calibrating is trivial. > Or are we saying here: oh well, there are so many ways for a normal guest to > be lied to so that we simply do the completely different approach and trust > the HV to be benevolent when we're not dealing with confidential guests which > have all those other things to keep the HV honest? This. Outside of CoCo, the hypervisor is 100% trusted. And there's zero reason for the hypervisor to lie, it can simply read/write all guest state.
Attempt to bring some amount of order to the PV clocks vs. TSC madness in the kernel. The primary goal of this series is to fix flaws with SNP and TDX guests where a PV clock provided by the untrusted hypervisor is used instead of the secure/trusted TSC that is controlled by trusted firmware. The secondary goal (last few patches) is to draft off of the SNP and TDX changes to slightly modernize running under KVM. Currently, KVM guests will use TSC for clocksource, but not sched_clock. And they ignore Intel's CPUID-based TSC and CPU frequency enumeration, even when using the TSC instead of kvmclock. And if the host provides the core crystal frequency in CPUID.0x15, then KVM guests can use that for the APIC timer period instead of manually calibrating the frequency. Lots more background: https://lore.kernel.org/all/20250106124633.1418972-13-nikunj@amd.com This is all *very* lightly tested (borderline RFC). Sean Christopherson (16): x86/tsc: Add a standalone helpers for getting TSC info from CPUID.0x15 x86/tsc: Add standalone helper for getting CPU frequency from CPUID x86/tsc: Add helper to register CPU and TSC freq calibration routines x86/sev: Mark TSC as reliable when configuring Secure TSC x86/sev: Move check for SNP Secure TSC support to tsc_early_init() x86/tdx: Override PV calibration routines with CPUID-based calibration x86/acrn: Mark TSC frequency as known when using ACRN for calibration x86/tsc: Pass KNOWN_FREQ and RELIABLE as params to registration x86/tsc: Rejects attempts to override TSC calibration with lesser routine x86/paravirt: Move handling of unstable PV clocks into paravirt_set_sched_clock() x86/paravirt: Don't use a PV sched_clock in CoCo guests with trusted TSC x86/kvmclock: Mark TSC as reliable when it's constant and nonstop x86/kvmclock: Get CPU base frequency from CPUID when it's available x86/kvmclock: Get TSC frequency from CPUID when its available x86/kvmclock: Stuff local APIC bus period when core crystal freq comes from CPUID x86/kvmclock: Use TSC for sched_clock if it's constant and non-stop arch/x86/coco/sev/core.c | 9 ++-- arch/x86/coco/tdx/tdx.c | 27 ++++++++-- arch/x86/include/asm/paravirt.h | 7 ++- arch/x86/include/asm/tdx.h | 2 + arch/x86/include/asm/tsc.h | 67 +++++++++++++++++++++++++ arch/x86/kernel/cpu/acrn.c | 5 +- arch/x86/kernel/cpu/mshyperv.c | 11 +++-- arch/x86/kernel/cpu/vmware.c | 9 ++-- arch/x86/kernel/jailhouse.c | 6 +-- arch/x86/kernel/kvmclock.c | 88 +++++++++++++++++++++++---------- arch/x86/kernel/paravirt.c | 15 +++++- arch/x86/kernel/tsc.c | 74 ++++++++++++++++----------- arch/x86/mm/mem_encrypt_amd.c | 3 -- arch/x86/xen/time.c | 4 +- 14 files changed, 243 insertions(+), 84 deletions(-) base-commit: ebbb8be421eefbe2d47b99c2e1a6dd840d7930f9