linux-kernel - Re: [PATCH 1/2] [net-next] packet: clarify timestamp overflow

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] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2017 15:25:29 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Hans Liljestrand <ishkamiel@...il.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "Rosen, Rami" <rami.rosen@...el.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Mike Maloney <maloney@...gle.com>,
        Sowmini Varadhan <sowmini.varadhan@...cle.com>,
        Network Development <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] [net-next] packet: clarify timestamp overflow

On Mon, Nov 27, 2017 at 11:17 AM, Arnd Bergmann <arnd@...db.de> wrote:
> The memory mapped packet socket data structure in version 1 through 3
> all contain 32-bit second values for the packet time stamps, which makes
> them suffer from the overflow of time_t in y2038 or y2106 (depending
> on whether user space interprets the value as signed or unsigned).
>
> The implementation uses the deprecated getnstimeofday() function.
>
> In order to get rid of that, this changes the code to use
> ktime_get_real_ts64() as a replacement, documenting the nature of the
> overflow. As long as the user applications treat the timestamps as
> unsigned, or only use the difference between timestamps, they are
> fine, and changing the timestamps to 64-bit wouldn't require a more
> invasive user space API change.
>
> Note: a lot of other APIs suffer from incompatible structures when
> time_t gets redefined to 64-bit in 32-bit user space, but this one
> does not.
>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

This change to avoid the deprecated internal interface looks great to me.

Acked-by: Willem de Bruijn <willemb@...gle.com>