Re: ✘64-bit time_t on glibc 2.34 and up

[Gary E. Miller]

Yo Miroslav!

On Mon, 16 Jan 2023 10:17:00 +0100
Miroslav Lichvar <mlichvar@redhat.com> wrote:

> On Thu, Jan 12, 2023 at 05:10:13PM -0800, Gary E. Miller wrote:
> > 4.  gpsd and ntpd always use 64-bit time_t going forward.  Admin
> > needs to mix and match.  
> 
> I suspect that wouldn't work, at least generally. It would prevent
> gpsd/ntpd from using a library which has time_t in its API, e.g.
> I see timevals in libusb.h. 

I agree, it is terrible as a general case.  But gpsd is a specific case,
narrowed by the specific case where _TIME_SIZE_BITS is even an option.
Mostly Raspberry Pi, and similar, distros that are not 64-bit yet.

As for gpsd and libusb.h.  Gpsd uses none of the timeval calls that
libusb offers.  NTPsec does not use libusb at all.

> I think it is expected to be a distro policy to select which time_t is
> used in all applications and have that -D_TIME_BITS=64 in some global
> CPPFLAGS/CFLAGS followed by all packages.

Maybe, but Gentoo does not.  When the disrtos decide we'll have no
choice but to follow.

> gpsd could make it easier
> for users compiling it themselves and check some known locations of
> these global flags.

I know of none.  If you do, please forward them to us.

> > 5.  1st process to open SHM(0) wins, the other process checks the
> > size to know the contents.  
> 
> This one makes most sense to me, if you feel you need to support both
> at the same time.

Except old apps stay around for decades.  Coding in data races is not
a good idea.  At least for shmTime, the current solution avoids that
mess.

> Instead of complicating the SHM support, I'd prefer if you deprecated
> it in favor of the SOCK or something else to avoid the security issue
> with untrusted applications creating the SHM segment before
> gpsd/ntpd/chronyd.

Now that you mention SOCK, we still do not have agreements on that.

> > 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
> > };  
> 
> It could check the length of the message, see if the magic value
> at the end is correct, and convert the message to the expected time_t
> if it doesn't match the one that was used in compilation.

If you want to do that in chrony, then gpsd can do the same.

I would like ntpd to also be able to read the SOCK.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@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

pgppw1CddM_xf.pgp
Description: OpenPGP digital signature