Date: Tue, 17 Dec 2019 00:08:09 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: probably need to emulate SO_TIMESTAMP It's come to my attention that a good deal of software uses SO_TIMESTAMP (the socket option for receiving timestamps as control messages attached to datagrams), whose definition changes for time64. Without any further measures, it fails with ENOPROTOOPT on pre-5.1 kernels. Some programs handle this gracefully; others treat it as a hard error. Apparently it's old enough, and widely available enough on non-Linux, that it's fairly "reasonable" to just assume it works. Since otherwise this looks like it's going to be a big breaking part of the time64 release, I'm strongly leaning towards emulating SO_TIMESTAMP (and SO_TIMESTAMPNS) for pre-5.1 kernels. This involves converting the setsockopt/getsockopt calls to use the old option as a fallback, but more importantly, having recvmsg scan and translate received control messages. A draft of the patch is attached. Since recvmsg can't distinguish between being called by a time32 binary (that intentionally requested SO_TIMESTAMP_OLD) and being called by a time64 binary (that got SO_TIMESTAMP_OLD as a fallback), it doesn't replace the old control message (this couldn't be done in-place anyway, since the new one is larger) but appends it. Programs running on pre-5.1 kernels, and all legacy time32 callers, will then see both SCM_TIMESTAMP_OLD and SCM_TIMESTAMP[_NEW] control messages, assuming both fit (if not, perhaps we should set MSG_CTRUNC flag like the kernel would). The related SO_TIMESTAMPING option is significantly harder to emulate in a feature-complete manner, since it allows SCM_TIMESTAMPING to be sent as a control message on a per-sendmsg basis, to control send timestamp generation. A feature-incomplete version could be done just like the other two, but it's not clear how beneficial that would be; from my research so far (Debian Code Search, mostly, after some initial reports of problems) it seems that SO_TIMESTAMPING is pretty much always treated as a feature that might or might not be present or work, and that absence is non-fatal. This makes sense because it's a lot newer and seems Linux-specific. One issue I've not mentioned yet is recvmmsg, which is an utter mess. The O(1)-space emulation approach that works for recvmsg becomes O(n) with recvmmsg, since there's nowhere to keep the original msg_controllen for each msghdr. This means we need to limit vlen, emulate it with recvmsg in a loop, or limit vlen in each loop iteration but loop until the whole requested vlen is completed or other exit conditions occur. My leaning would be just calling recvmmsg in a loop since this whole function is such a mess. Thoughts? Any potential problems with the attached? Rich View attachment "emulate_so_timestamp.diff" of type "text/plain" (4430 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.