✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo All!

Cross-posted to gpsd-dev and devel at ntpsec.org

Recent glibc (2.34 and up) and recent Linux kernels, allow 64 bit
time_t on 32-bit Linux without much work.

But...

How to get that 2038 compatible time to ntpd and chronyd?  That is a
much bigger problem.

Extracted from include/ntpshm.h:

struct shmTime
{
    int mode;
    volatile int count;
    time_t clockTimeStampSec;
    int clockTimeStampUSec;
    time_t receiveTimeStampSec;
    int receiveTimeStampUSec;
    int leap;                   // not leapsecond offset, a notification code
    int precision;              // log(2) of source jitter
    int nsamples;               // not used
    volatile int valid;
    unsigned        clockTimeStampNSec;     // Unsigned ns timestamps
    unsigned        receiveTimeStampNSec;   // Unsigned ns timestamps
    int             dummy[8];
};

Note the struct size depends on the size of an int, and the size of time_t.

This is no problem for newer musl on 32-bits. An int is 32-bits and
time_t is 64.  Assuming all clients use the same version musl.

This is a problem for glibc on 32 bits. And int is 32-bits, but time_t
is a compile time option (32 or 64 bits).

How does ntpd know what size time_t to use? And thus know the size of
shmTime?  How do we know portably, preserving backwards and forwards
compatibility?

In hindsight, maybe shmTime should have started with a 1 char version
field,or magic field.  But, no such luck.

Options (for 32-bit only):

1.  Do nothing, stick with 32-bit time_t. Fail in 2038.

2.  Allow 64-bit time_t and let incompatible ntpd fail.

3.  Add run time options to gpsd and ntpd to specify time_t size.

4.  gpsd and ntpd always use 64-bit time_t going forward.  Admin needs
to mix and match.

5.  1st process to open SHM(0) wins, the other process checks the size
to know the contents.

6.  Create a new way to pass time from gpsd to ntpd and chronyd.

Also note, chrony sockets have a similar problem:

#define SOCK_MAGIC 0x534f434b
struct sock_sample {
    struct timeval tv;
    double offset;
    int pulse;
    int leap;       // notify that a leap second is upcoming
    int _pad;
    int magic;      // must be SOCK_MAGIC
};

Where timeval is:

struct timeval {
    time_t          tv_sec;
    suseconds_t     tv_usec;
};
```

Since the sample has a magic value, maybe that can be used to detect versions.

This makes my head hurt...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20230112/5a0ac059/attachment.bin>