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

[Fred Wright]

On Tue, 24 Dec 2024, Gary E. Miller via devel wrote:

> On Tue, 24 Dec 2024 15:21:14 -0800 (PST)
> Fred Wright via devel <devel at ntpsec.org> wrote:
>
>> On Tue, 24 Dec 2024, Gary E. Miller (@garyedmundsmiller) wrote:
>>> Gary E_ Miller
>>> commented: https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1414#note_2273464732
>>>
>>>
>>> I don't know about OSX, but this is not the proper GNU libc fix.
>>>
>>> With GNU libc, the size of time_t on 32-bit ABI depends on two
>>> #defines.
>>>
>>> '-D_FILE_OFFSET_BITS=64', '-D_TIME_BITS=64',
>>>
>>> This is the nut of issue #832.  No heuristics needed, just check
>>> the two #define.  And they change a more than just time_t.
>>
>> You're missing the point.  If the format of the timestamp returned
>> with the packet differs from the userspace format that the userspace
>> code expects (regardless of what that userspace format is), the
>> timestamp needs to be converted.
>
> 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.  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.

The issue is that the kernel provides a struct timeval or struct timespec 
based on *its* notion of time_t.  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.

Dealing with this in userspace is straightforward, 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.

It's unlikely that the problem is nonexistent on Linux, but it may be that 
glibc for Linux handles it internally and makes it invisible to the 
caller.  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.

Fred Wright