linux-kernel - Re: [RFC] y2038: HCI_TIME

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5E8DACB3-3B53-4E22-A834-4CEDFC6A1757@holtmann.org>
Date:   Fri, 10 Jan 2020 16:44:54 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Arnd Bergmann <arnd@...db.de>
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>
Subject: Re: [RFC] y2038: HCI_TIME_STAMP with time64

Hi Arnd,

> 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.
> 
> The interface was originally added back in 2002 by Maksim Krasnyanskiy
> when bluetooth support first became non-experimental.
> 
> 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.
> 
> Fixing this the same was as normal socket timestamps is not possible
> because include/net/bluetooth/hci.h is not an exported UAPI header.
> This means any changes to it for defining HCI_TIME_STAMP conditionally
> would be ignored by applications that use a different copy of the
> header.
> 
> I can see three possible ways forward:
> 
> 1. move include/net/bluetooth/hci.h to include/uapi/, add a conditional
>   definition of HCI_TIME_STAMP and make the kernel code support
>   both formats. Then change applications to rely on that version of
>   header file to get the correct definition but not change application code.
> 
> 2. Leave the kernel completely unchanged and modify only the users
>    to not expect the output to be a 'struct timeval' but interpret as
>    as { uint32_t tv_sec; int32_t tv_usec; } structure on 32-bit architectures,
>    which will work until the unsigned time overflows 86 years from now
>    in 2106 (same as the libpcap on-disk format).
> 
> 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.

Regards

Marcel