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@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
_______________________________________________
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
