lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 10 Jan 2020 17:08:23 +0100 From: Arnd Bergmann <arnd@...db.de> To: Marcel Holtmann <marcel@...tmann.org> Cc: Bluez mailing list <linux-bluetooth@...r.kernel.org>, y2038 Mailman List <y2038@...ts.linaro.org>, Johan Hedberg <johan.hedberg@...il.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Deepa Dinamani <deepa.kernel@...il.com>, Rich Felker <dalias@...c.org>, Guy Harris <guy@...m.mit.edu> Subject: Re: [RFC] y2038: HCI_TIME_STAMP with time64 On Fri, Jan 10, 2020 at 4:44 PM Marcel Holtmann <marcel@...tmann.org> wrote: > > I noticed earlier this week that the HCI_CMSG_TSTAMP/HCI_TIME_STAMP > > interface has no time64 equivalent, as we apparently missed that when > > converting the normal socket timestamps to support both time32 and time64 > > variants of the sockopt and cmsg data. ... > > When using HCI_TIME_STAMP on a 32-bit system with a time64 > > libc, users will interpret the { s32 tv_sec; s32 tv_usec } layout of > > the kernel as { s64 tv_sec; ... }, which puts complete garbage > > into the timestamp regardless of whether this code runs before or > > after y2038. From looking at codesearch.debian.org, I found two > > users of this: libpcap and hcidump. There are probably others that > > are not part of Debian. ... > > 3. Add support for the normal SO_TIMESTAMPNS_NEW sockopt in > > HCI, providing timestamps in the unambiguous { long long tv_sec; > > long long tv_nsec; } format to user space, and change applications > > to use that if supported by the kernel. > > I have added SO_TIMESTAMP* to every Bluetooth socket a while back. And that should be used by the majority of the tools. One exception might by hcidump which has been replaced by btmon already anyway. > > So I would not bother with HCI_TIME_STAMP fixing. We can do 2) if someone really still wants to use that socket option. However I am under the impression that 3) should be already possible. Ok, excellent, I had not realized this works already. I have now also checked https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-bt-monitor-linux.c which uses SO_TIMESTAMP and then should work. I guess this is similar to what btmon does. For libpcap that leaves https://github.com/the-tcpdump-group/libpcap/blob/master/pcap-bt-linux.c#L358 which needs a fairly simply fix on 32-bit architectures to copy the two 32-bit fields into the longer pkth.ts fields individually rather than using a memcpy. I've added Guy Harris to Cc, he seems to be the maintainer for this file according to the git history. The same change is needed for https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/hcidump.c#n233 if there are any remaining users. I can send you a patch if you want. Arnd
Powered by blists - more mailing lists