linux-kernel - Re: [PATCH] kvm: kvmclock: let KVM_GET_CLOCK return whether the master clock is in use

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]

Date:   Wed, 9 Nov 2016 19:14:07 -0200
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Radim Krčmář <rkrcmar@...hat.com>
Subject: Re: [PATCH] kvm: kvmclock: let KVM_GET_CLOCK return whether the
 master clock is in use

On Wed, Nov 09, 2016 at 06:17:16PM -0200, Marcelo Tosatti wrote:
> On Wed, Nov 09, 2016 at 06:12:50PM -0200, Marcelo Tosatti wrote:
> > On Wed, Nov 09, 2016 at 05:48:15PM +0100, Paolo Bonzini wrote:
> > > Userspace can read the exact value of kvmclock by reading the TSC
> > > and fetching the timekeeping parameters out of guest memory.  This
> > > however is brittle and not necessary anymore with KVM 4.11.  
> > 
> > Hi Paolo,
> > 
> > Can you point to commit or explanation why that is not the case anymore?
> > Thanks
> 
> I don't see how thats possible given the:
> 
>  * TSC 
>  * TSC (timer interrupt + TSC deltas) (AKA host TSC clocksource and
>  * CLOCK_MONOTONIC).
>  
> Clocks currently drift from each other (therefore are not monotonic).
> 
> Have you confirmed CLOCK_MONOTONIC_RAW and TSC are monotonic?

I think the benefits of CLOCK_MONOTONIC_RAW (which supposedly 
is monotonic with TSC for large lenghts of time) outweight the 
downsides (just have to check that).

The downsides are that on migration from

    source: TSC with freq Y.
    dest: TSC with freq X.

Suddenly kvmclock starts drifting at a different rate, 
unsure how well Windows time service and 
older NTPd respond to this (might be a regression).