linux-kernel - Re: Setting real-time clock below monotonic clock

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

Message-ID: <CANDhNCoh3O=Ds_oLkGer7KKVUW4Zdf_vDdDmyJFVKhDSGU5c-g@mail.gmail.com>
Date: Wed, 31 Jan 2024 11:12:34 -0800
From: John Stultz <jstultz@...gle.com>
To: Joseph Beckenbach <Joseph.Beckenbach@...com>
Cc: "tglx@...utronix.de" <tglx@...utronix.de>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Setting real-time clock below monotonic clock

On Wed, Jan 31, 2024 at 10:48 AM Joseph Beckenbach
<Joseph.Beckenbach@...com> wrote:
>
> We have observed that we are not able to set the realtime clock’s time value below the monotonic clock’s time value in the Linux kernel.
>

Indeed. That behavior was intentional.

>
> We have a situation where we will try to set the realtime clock time to a very low value (close to January 1, 1970) and below the monotonic clock value. In this situation, it does not matter what the date is, but we need the time to be synchronized across multiple devices (using generalized Precision Time Protocol or gPTP) for our application. It’s possible this synchronized time might be a low value (close to 1970) because the gPTP master starts its time from January 1, 1970 when it is booted, and when this gPTP master is booted after the gPTP slave, the master’s time is larger than the slave’s monotonic clock (which also starts from 0 when it is booted). When the slave tries to adjust its clock to match the master, we get an error.
>

I appreciate there may be many constraints here, but it feels like the
device you're trying to sync to, reporting its time as close to Jan 1
1970 is misconfigured.
So I'm not sure it's reasonable to expect the kernel to support that case.

Is there some different perspective I'm missing, though?

>
> Currently, we are planning to use a workaround where we keep track of a known offset between the “synchronized” time which is 1970 and the “real time” such as 2024. Since the time only jumps once at the beginning of sync and should not change by more than a second afterwards, we think this will work for now.
>

It seems if the device you're syncing to would start its configured
time from date even slightly closer to now (start with 1980!), it
would also avoid the problem?

>
> We currently do not want to spend time pushing for a change in the Linux kernel. But I wanted to at least report this use case we have and the issue we are having because of this behavior in the Linux kernel.
>

I'm sorry I don't have a better response for you here, but I
appreciate you sending out the mail. It's nice to have more folks
working on time/time sync interacting on the list.

thanks
-john