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: <87o8f26m8c.ffs@nanos.tec.linutronix.de>
Date:   Mon, 29 Mar 2021 16:57:55 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Richard Cochran <richardcochran@...il.com>,
        Miroslav Lichvar <mlichvar@...hat.com>
Cc:     Daphne Preston-Kendall <dpk@...ceword.org>,
        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 Mon, Mar 29 2021 at 07:26, Richard Cochran wrote:
> On Mon, Mar 29, 2021 at 11:16:48AM +0200, Miroslav Lichvar wrote:
>> 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.
>
> I not losing sleep over that, but
>
>> 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.
>
> oh, I didn't think of that.  I hate leap seconds.  Good thing Earth is
> picking up the pace again!
>  
>> 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.
>
> I think it wiser to provide another way, sysfs or something else.

I think adjtimex is the right place and not yet another random file
somewhere. Something like the below.

Thanks,

        tglx
---
 include/uapi/linux/timex.h |    7 +++++--
 kernel/time/ntp.c          |    4 +++-
 2 files changed, 8 insertions(+), 3 deletions(-)

--- a/include/uapi/linux/timex.h
+++ b/include/uapi/linux/timex.h
@@ -188,9 +188,12 @@ struct __kernel_timex {
 #define STA_MODE	0x4000	/* mode (0 = PLL, 1 = FLL) (ro) */
 #define STA_CLK		0x8000	/* clock source (0 = A, 1 = B) (ro) */
 
+#define STA_TAISET	0x10000 /* TAI offset was set via adjtimex (ro) */
+
 /* read-only bits */
-#define STA_RONLY (STA_PPSSIGNAL | STA_PPSJITTER | STA_PPSWANDER | \
-	STA_PPSERROR | STA_CLOCKERR | STA_NANO | STA_MODE | STA_CLK)
+#define STA_RONLY (STA_PPSSIGNAL | STA_PPSJITTER | STA_PPSWANDER |	\
+		   STA_PPSERROR | STA_CLOCKERR | STA_NANO | STA_MODE |	\
+		   STA_CLK | STA_TAISET)
 
 /*
  * Clock states (time_state)
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -741,8 +741,10 @@ static inline void process_adjtimex_mode
 	}
 
 	if (txc->modes & ADJ_TAI &&
-			txc->constant >= 0 && txc->constant <= MAX_TAI_OFFSET)
+	    txc->constant >= 0 && txc->constant <= MAX_TAI_OFFSET) {
 		*time_tai = txc->constant;
+		time_status |= STA_TAISET;
+	}
 
 	if (txc->modes & ADJ_OFFSET)
 		ntp_update_offset(txc->offset);