> On 01/12/2023 5:10 PM PST Gary E. Miller <g...@rellim.com> wrote:
>
>
> Yo All!
>
> Cross-posted to gpsd-dev and devel@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...
IIRC there are a few users of those interfaces; linuxptp, gpsd,
classic NTP, NTPsec, and chrony. I would jokingly suggest
something like the following as a replacement. Purely based on
the misassumption that SHM internally works on page-sized blocks
and probably via POSIX shared memory which would allow names.
Also, the mode should be 640, and the root user should not be
remotely involved.
```c
typedef struct {
uint32_t left_book;
uint32_t mode; // modes 4-7 match this
uint32_t half_epoch; /* number of 2^31 seconds since
1900-01-01T00:00:00Z */
uint32_t c_seconds; /* coarse time from string mangling
probably */
uint32_t c_nseconds;
uint32_t f_seconds; /* fine time probably from a pulse
per second */
uint32_t f_nseconds;
signed int32_t leap;
signed int32_t precision;
uint32_t padding[1013]; // I think it should be 1014
uint32_t right_book;
} pshm_t;
```
The low two bits of mode could be the validity of coarse and
fine time, respectively. Anyone needing microsecond or NTP
partial seconds can math it.
Posted to gpsd issue #152 earlier, gpsd-dev, and NTPsec devel.
- JamesB192
I'm supposed to put a signature here...
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
