linux-kernel - Re: [PATCH] pktgen: document 32-bit 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:   Wed, 08 Nov 2017 15:56:47 +0900 (KST)
From:   David Miller <davem@...emloft.net>
To:     arnd@...db.de
Cc:     stephen@...workplumber.org, fan.du@...driver.com,
        edumazet@...gle.com, john.fastabend@...il.com, oleg@...hat.com,
        ast@...mgrid.com, minipli@...glemail.com, tgraf@...g.ch,
        johannes.berg@...el.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pktgen: document 32-bit timestamp overflow

From: Arnd Bergmann <arnd@...db.de>
Date: Tue,  7 Nov 2017 11:38:32 +0100

> Timestamps in pktgen are currently retrieved using the deprecated
> do_gettimeofday() function that wraps its signed 32-bit seconds in 2038
> (on 32-bit architectures) and requires a division operation to calculate
> microseconds.
> 
> The pktgen header is also defined with the same limitations, hardcoding
> to a 32-bit seconds field that can be interpreted as unsigned to produce
> times that only wrap in 2106. Whatever code reads the timestamps should
> be aware of that problem in general, but probably doesn't care too
> much as we are mostly interested in the time passing between packets,
> and that is correctly represented.
> 
> Using 64-bit nanoseconds would be cheaper and good for 584 years. Using
> monotonic times would also make this unambiguous by avoiding the overflow,
> but would make it harder to correlate to the times with those on remote
> machines. Either approach would require adding a new runtime flag and
> implementing the same thing on the remote side, which we probably don't
> want to do unless someone sees it as a real problem. Also, this should
> be coordinated with other pktgen implementations and might need a new
> magic number.
> 
> For the moment, I'm documenting the overflow in the source code, and
> changing the implementation over to an open-coded ktime_get_real_ts64()
> plus division, so we don't have to look at it again while scanning for
> deprecated time interfaces.
> 
> Signed-off-by: Arnd Bergmann <arnd@...db.de>

Applied to net-next, thanks Arnd.