ntpsec | ntp_packetstamp: Fix possible time_t size mismatch. (!1414)

[Gary E. Miller]

Yo Fred!

On Tue, 24 Dec 2024 17:22:42 -0800 (PST)
Fred Wright via devel <devel at ntpsec.org> wrote:

> > Sorry, I should have read closer, if you are just looking at the
> > on the wire NTP packet then my comments are not on point.  I though
> > the NTP packets were fixed by RFC?  
> 
> No, this has nothing to do with the packet on the wire.  It also has 
> nothing to do with issue 832.

Except both this and that, and other issues, relate to the mess that is
'-D_FILE_OFFSET_BITS=64', '-D_TIME_BITS=64',


> It has to do with packets' *locally 
> captured* timestamps that are provided as auxiliary data when
> requested by socket options SO_TIMESTAMP, SO_CLOCK, or SO_TIMESTAMPNS.

Can you be more spefic about the exact structures affected?

> The issue is that the kernel provides a struct timeval or struct
> timespec based on *its* notion of time_t.

Yes, and libc is supposed to convert as required.  I know GNU libc does.
At least at the parts I have looked at.

> Although it can presumably
> know the bitness of the relevant process (though whether that's
> plumbed through to the relevant code is questionable), it doesn't
> necessarily know what options the userspace code is built with, so
> the version of timeval/timespec it's returning may not match the
> userspace definition.

That is handled, at least on Linux, bu GNU libc and the two relevant
defines:
'-D_FILE_OFFSET_BITS=64', '-D_TIME_BITS=64',

So this appears to be OSC specific.  Right?

> Dealing with this in userspace is straightforward,

And not needed other than OSX?

> because the size
> of the timestamp-containing cmsg provided along with the packet is
> contained in the cmsghdr, and the payload size should be either 8 or
> 12, depending on the kernel's time_t size.  The userspace code can
> then either use it verbatim if it's the expected size, or convert it
> by copying if it's not.

Yes, this is how chronyd handles SHM from gpsd.  Just checks the size.

> It's unlikely that the problem is nonexistent on Linux,

It exists, but in a completely different form.  As in bug 832.  All
the libc calls are handled by GNU libc.  

I'm happy to run any tests you wish.

> but it may be
> that glibc for Linux handles it internally and makes it invisible to
> the caller.

Somewhat.  Like bug 832 where a time_t no longer fits in a (void*).

> In that case, the wrapper function is just a harmless
> (and probably desirable) sanity check on the cmsg length, plus a
> handful of unreachable CPU instructions.

Since is seems OSX specific I'd like a check either for OSX.

Are you sure that OSC has nothing like: 
    '-D_FILE_OFFSET_BITS=64', '-D_TIME_BITS=64',

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