linux-kernel - Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock periodically

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: <9975969725a64c2ba2b398244dba3437bff5154e.camel@infradead.org>
Date:   Tue, 03 Oct 2023 06:54:56 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Dongli Zhang <dongli.zhang@...cle.com>,
        Joe Jin <joe.jin@...cle.com>, x86@...nel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com
Subject: Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock
 periodically

On Mon, 2023-10-02 at 17:53 -0700, Sean Christopherson wrote:
> 
> The two domains use the same "clock" (constant TSC), but different math to compute
> nanoseconds from a given TSC value.  For decently large TSC values, this results
> in CLOCK_MONOTONIC_RAW and kvmclock computing two different times in nanoseconds.

This is the bit I'm still confused about, and it seems to be the root
of all the other problems.

Both CLOCK_MONOTONIC_RAW and kvmclock have *one* job: to convert a
number of ticks of the TSC running at a constant known frequency, to a
number of nanoseconds.

So how in the name of all that is holy do they manage to get
*different* answers?

I get that the mult/shift thing carries some imprecision, but is that
all it is? Can't we ensure that the kvmclock uses the *same* algorithm,
precisely, as CLOCK_MONOTONIC_RAW?

> E.g. IIUC, your proposed patch to use a single RDTSC[*] eliminates the drift by
> undoing the CLOCK_MONOTONIC_RAW crap using the same TSC value on both the "add"
> and the "subtract", but the underlying train wreck of mixing time domains is
> still there.

> [*] https://lore.kernel.org/all/ee446c823002dc92c8ea525f21d00a9f5d27de59.camel@infradead.org

That one's different; those clock domains are *supposed* to be
divergent and the point in the PV wall clock information is to convey
the delta between the two. I just made it use the delta between the two
at a *given* moment, instead of calculating the difference between
*two* different times.

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