linux-kernel - Re: [PATCH] KVM: x86/xen: improve accuracy of Xen timers

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: <ae179410922c40cbca7a2e9a94a6695db6eae069.camel@infradead.org>
Date:   Tue, 31 Oct 2023 22:38:31 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Griffoul, Fred" <fgriffo@...zon.com>
Cc:     Paul Durrant <paul@....org>,
        Sean Christopherson <seanjc@...gle.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>
Subject: Re: [PATCH] KVM: x86/xen: improve accuracy of Xen timers

On Tue, 2023-10-31 at 19:45 +0000, David Woodhouse wrote:
> On Mon, 2023-10-30 at 15:50 +0000, David Woodhouse wrote:
> > 
> > +static int do_monotonic(s64 *t, u64 *tsc_timestamp)
> > +{
> > +	struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
> > +	unsigned long seq;
> > +	int mode;
> > +	u64 ns;
> > +
> > +	do {
> > +		seq = read_seqcount_begin(&gtod->seq);
> > +		ns = gtod->clock.base_cycles;
> > +		ns += vgettsc(&gtod->clock, tsc_timestamp, &mode);
> > +		ns >>= gtod->clock.shift;
> > +		ns += ktime_to_ns(ktime_add(gtod->clock.offset, gtod->offs_boot));
> > +	} while (unlikely(read_seqcount_retry(&gtod->seq, seq)));
> > +	*t = ns;
> > +
> > +	return mode;
> > +}
> > +
> 
> Hrm, that's basically cargo-culted from do_monotonic_raw() immediately
> above it. Should it be adding gtod->offs_boot?
> 
> Empirically the answer would appear to be 'no'. When gtod->offs_boot is
> non-zero, I see kvm_get_monotonic_and_clockread() returning values
> which are precisely that far in advance of what ktime_get() reports.


.... because the do_monotonic_raw() function, despite the simple
clarity of its name... doesn't actually return the CLOCK_MONOTONIC_RAW
time. Of course it doesn't. Why would a function with that name return
the MONOTONIC_RAW clock?

It actually returns the same as get_kvmclock_base_ns(), which is

	/* Count up from boot time, but with the frequency of the raw clock.  */
	return ktime_to_ns(ktime_add(ktime_get_raw(), pvclock_gtod_data.offs_boot));

I feel that Grey's Law is starting to apply to this clock stuff. This
is starting to be indistinguishable from malice ;)


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)