netdev - Re: [PATCH net-next] drop_monitor: Make timestamps y2038 safe

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]

Message-ID: <CAK8P3a21AeWTvm1+roStbMGHCkK0tWcuWc-Dk-J_5Ea+XTPUMA@mail.gmail.com>
Date:   Tue, 27 Aug 2019 15:10:56 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Networking <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Neil Horman <nhorman@...driver.com>,
        Andrew Lunn <andrew@...n.ch>, Aya Levin <ayal@...lanox.com>,
        mlxsw@...lanox.com, Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH net-next] drop_monitor: Make timestamps y2038 safe

On Fri, Aug 23, 2019 at 5:48 PM Ido Schimmel <idosch@...sch.org> wrote:
>
> From: Ido Schimmel <idosch@...lanox.com>
>
> Timestamps are currently communicated to user space as 'struct
> timespec', which is not considered y2038 safe since it uses a 32-bit
> signed value for seconds.
>
> Fix this while the API is still not part of any official kernel release
> by using 64-bit nanoseconds timestamps instead.
>
> Fixes: ca30707dee2b ("drop_monitor: Add packet alert mode")
> Fixes: 5e58109b1ea4 ("drop_monitor: Add support for packet alert mode for hardware drops")
> Signed-off-by: Ido Schimmel <idosch@...lanox.com>
> ---
> Arnd, I have followed your recommendation to use 64-bit nanoseconds
> timestamps. I would appreciate it if you could review this change.

somewhat late reply:


> @@ -761,8 +759,8 @@ static int net_dm_hw_packet_report_fill(struct sk_buff *msg,
>                         goto nla_put_failure;
>         }
>
> -       if (ktime_to_timespec_cond(skb->tstamp, &ts) &&
> -           nla_put(msg, NET_DM_ATTR_TIMESTAMP, sizeof(ts), &ts))
> +       if (nla_put_u64_64bit(msg, NET_DM_ATTR_TIMESTAMP,
> +                             ktime_to_ns(skb->tstamp), NET_DM_ATTR_PAD))
>                 goto nla_put_failure;
>
>         if (nla_put_u32(msg, NET_DM_ATTR_ORIG_LEN, skb->len))

Yes, this looks reasonable. I guess since we take the skb timestamps
in CLOCK_REALTIME, there is little point in trying to use
CLOCK_MONOTONIC in the user interface.

64-bit nanoseconds are safe for a few hundred years.

       Arnd