diff options
author | Arnd Bergmann <arnd@arndb.de> | 2018-07-11 12:16:12 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2018-07-12 14:50:40 -0700 |
commit | cca9bab1b72cd2296097c75f59ef11ef80461279 (patch) | |
tree | 2262a12f93e2a0977d5259bca9b74eee89f33c88 /drivers/crypto/bcm | |
parent | d2bdd2681278d66fd34cd8e0cf724de918f429b2 (diff) | |
download | op-kernel-dev-cca9bab1b72cd2296097c75f59ef11ef80461279.zip op-kernel-dev-cca9bab1b72cd2296097c75f59ef11ef80461279.tar.gz |
tcp: use monotonic timestamps for PAWS
Using get_seconds() for timestamps is deprecated since it can lead
to overflows on 32-bit systems. While the interface generally doesn't
overflow until year 2106, the specific implementation of the TCP PAWS
algorithm breaks in 2038 when the intermediate signed 32-bit timestamps
overflow.
A related problem is that the local timestamps in CLOCK_REALTIME form
lead to unexpected behavior when settimeofday is called to set the system
clock backwards or forwards by more than 24 days.
While the first problem could be solved by using an overflow-safe method
of comparing the timestamps, a nicer solution is to use a monotonic
clocksource with ktime_get_seconds() that simply doesn't overflow (at
least not until 136 years after boot) and that doesn't change during
settimeofday().
To make 32-bit and 64-bit architectures behave the same way here, and
also save a few bytes in the tcp_options_received structure, I'm changing
the type to a 32-bit integer, which is now safe on all architectures.
Finally, the ts_recent_stamp field also (confusingly) gets used to store
a jiffies value in tcp_synq_overflow()/tcp_synq_no_recent_overflow().
This is currently safe, but changing the type to 32-bit requires
some small changes there to keep it working.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/crypto/bcm')
0 files changed, 0 insertions, 0 deletions