linux-kernel - Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

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: <2505F20D-ED84-4B36-9504-8A8C756C992E@nonceword.org>
Date:   Mon, 29 Mar 2021 11:56:31 +0200
From:   Daphne Preston-Kendal <dpk@...ceword.org>
To:     Miroslav Lichvar <mlichvar@...hat.com>
Cc:     Richard Cochran <richardcochran@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Subject: Re: [Bug 212265] New: clock_gettime(CLOCK_TAI, ...) should return an error when TAI has not been configured

On 29 Mar 2021, at 11:16, Miroslav Lichvar <mlichvar@...hat.com> wrote:

> On Fri, Mar 26, 2021 at 08:28:59PM -0700, Richard Cochran wrote:
>> Using ntpd on Debian, the service will set the offset, but only after
>> synchronization with the upstream server has been established, and
>> this takes about five minutes, IIRC.
> 
> With the iburst option it shouldn't take more than 10 seconds. There
> might be an issue wrt stepping the clock when the initial offset is
> large. In Fedora and derived distros using chrony by default the
> TAI-UTC offset should be set right on the first update of the clock as
> expected.

Yeah, I personally am not really concerned about the immediate post-boot environment. As long as it’s ready by the time userland services are starting, I think most applications that need TAI will be satisfied.

>> Getting back to the original point of the kernel returning an error,
>> I don't see a need for this.  Applications that require correct leap
>> seconds can simply call adjtimex() and wait until the initial zero
>> value is changed by ntpd/etc to the correct offset.  That isn't
>> fundamentally harder than calling clock_gettime() and waiting until
>> the error would go away.
> 
> There are at least two issues with handling a zero offset as a special
> value. One is that zero could potentially be a valid value in distant
> future.

Since even a single negative leap second was, until recently, considered (quite literally) astronomically unlikely, and even now (where the earth is spinning faster than ever hitherto expected) the most likely scenario by far seems to be that it’ll just be a longer wait than usual for the next positive leap second, I’d say minus 37 leap seconds is a prospect for the very very distant future indeed. But in theory, yes.

> The other is that the kernel updates the offset when a leap
> second is inserted/deleted even if the original offset is zero, so
> checking for zero (in the kernel or an application) works only until
> the first leap second after boot.

This is a problem and definitely speaks for having a way to tell whether CLOCK_TAI has been set up at all.

> The kernel would need to set a flag that the offset was set. Returning
> an error in clock_gettime() until the offset is set sounds reasonable
> to me, but I have no idea how many of the existing applications it
> would break.

Given that CLOCK_TAI doesn’t exist except on Linux, any portable Unix application is likely to have a fallback of some kind, though perhaps only at compile time.

Daphne Preston-Kendal