linux-kernel - Re: Missing CLOCK_BOOTTIME

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: <20200518111103.sj73h5j3r75zv2wp@pali>
Date:   Mon, 18 May 2020 13:11:03 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Missing CLOCK_BOOTTIME_RAW?

On Saturday 09 May 2020 11:49:27 Thomas Gleixner wrote:
> Pali,
> 
> Pali Rohár <pali@...nel.org> writes:
> > On Friday 08 May 2020 22:59:57 Thomas Gleixner wrote:
> >> Pali Rohár <pali@...nel.org> writes:
> >> Neither CLOCK_BOOTTIME nor CLOCK_MONOTONIC jump. They are frequency
> >> corrected when NTP, PTP or PPS are in use. The frequency correction is
> >> incremental an smothed. They really don't jump and they give you proper
> >> time in nanoseconds which is as close to the real nanoseconds as it
> >> gets.
> >
> > Hello! I should have been more precise about it. CLOCK_BOOTTIME and
> > CLOCK_MONOTONIC do not jump but I understood that they are affected by
> > adjtime(). So these clocks may tick faster or slower than real time. NTP
> > daemon when see that CLOCK_REALTIME is incorrect, it may speed up or
> > slow down its ticking. And this is affected also by CLOCK_BOOTTIME and
> > CLOCK_MONOTONIC, right?
> 
> Sure, but what's the problem? The adjustemt is done to make the observed
> time as correct as possible.

Yes. But correction may take lot of time, e.g. also more then one day.

So during this period when correction is in progress, measuring time
difference via CLOCK_MONITONIC will have incorrect results.

It already happened for me, system clock was shifted by one hour and
chronyd started adjustment, it slow down system clock. 6 real hours
passed and via system clock was measured time difference only about
5 hours and 20 minutes (correction was still in progress as system
clock at that time was still shifted by about 20 minutes).

So measuring time differences via clock affected by NTP adjustment
resulted in error which was more then 30 minutes.

CLOCK_MONOTONIC_RAW is not affected by this correction progress, so it
should gives better results. Or not?

> > You wrote that this clock is subject to drifts. What exactly may happen
> > with CLOCK_MONOTONIC_RAW?
> 
>   1) As the frequency of the raw clock is an estimate, resulting time
>      is drifting apart vs. the correct frequency.
> 
>   2) Depending on the crystal/oszillator there can be temperatur drift as
>      well.
> 
> Just for clarification. Even with NTP/PTP adjustment the resulting time
> stamps are never going to be precise vs. an atomic clock, but good
> enough for 99.9999% of the problems.

Ok, so it looks like that CLOCK_MONOTONIC_RAW is not the best choice.

> TBH, I have no idea what real world problem you are trying to solve.

Problem is simple: Measure time difference between two events and not to
be affected by the fact that system clock on machine is incorrect or
that time daemon is actually adjusting time.

I need to know if difference between those two events in more then some
period or not.

So if I want to know if time difference is more then 5 hours and 40
minutes then measurement via clock which is affected by NTP adjustment
would give me wrong result. As described above in reality 6 hours
passed but clock measured only 5 hours and 20 minutes.

> Thanks,
> 
>         tglx