linux-kernel - Re: [PATCH] KVM: x86: Update Xen TSC leaves during CPUID emulation

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] [day] [month] [year] [list]

Message-ID: <Z5OqnrPh6Pa2LXZT@google.com>
Date: Fri, 24 Jan 2025 06:58:38 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: paul@....org
Cc: David Woodhouse <dwmw2@...radead.org>, Fred Griffoul <fgriffo@...zon.co.uk>, kvm@...r.kernel.org, 
	griffoul@...il.com, vkuznets@...hat.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>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Update Xen TSC leaves during CPUID emulation

On Fri, Jan 24, 2025, Paul Durrant wrote:
> This LGTM. My only concern is whether vcpu->arch.hv_clock will be updated by
> anything other than a KVM_REQ_CLOCK_UPDATE?

Once the "full" vcpu->arch.hv_clock is gone and only the multiplier+shift are
left behind, the probability of rogue changes to those fields should go down.
I'll also add a comment explaining the relationship between hw_tsc_khz,
pvclock_tsc_shift, and pvclock_tsc_mul, which I should have done it for v1.

https://lore.kernel.org/all/20250118005552.2626804-9-seanjc@google.com

> I don't think so but the crucial thing is that the values match what is in
> the vcpu_info struct... so maybe a safer option is to pull the values
> directly from that.

But that relies on the XEN PV clock to be active, which I don't think can be
guaranteed.  And even if that isn't a concern, I think we're doomed either way
if any of the relevant fields get clobbered.  Hah, actually we're doomed, period.

E.g. if KVM emulates CPUID, and then before resuming the guest reacts to a TSC
frequency change, the values returned by CPUID will diverge from what gets stored
into the PV clock.

In general, if the TSC isn't stable, using the info from CPUID instead of the
PV clock itself is a guest bug, because only the PV clock provides a sequence
counter to ensure reading time is consistent.