[TCP]: secure_tcp_sequence_number() should not use a too fast clock (9b42c336) · Commits · 戴 / test

TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock. In order to follow network speed increase, we can use a faster clock, but we should limit this clock so that the delay between two rollovers is greater than MSL (TCP Maximum Segment Lifetime : 2 minutes) Choosing a 64 nsec clock should be OK, since the rollovers occur every 274 seconds. Problem spotted by Denys Fedoryshchenko [ This bug was introduced by ] Signed-off-by:

Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:

David S. Miller <davem@davemloft.net>

drivers/char/random.c

+6 −4

Original line number	Diff line number	Diff line
		@@ -1550,11 +1550,13 @@ __u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
		* As close as possible to RFC 793, which
		* suggests using a 250 kHz clock.
		* Further reading shows this assumes 2 Mb/s networks.
		* For 10 Gb/s Ethernet, a 1 GHz clock is appropriate.
		* That's funny, Linux has one built in! Use it!
		* (Networks are faster now - should this be increased?)
		* For 10 Mb/s Ethernet, a 1 MHz clock is appropriate.
		* For 10 Gb/s Ethernet, a 1 GHz clock should be ok, but
		* we also need to limit the resolution so that the u32 seq
		* overlaps less than one time per MSL (2 minutes).
		* Choosing a clock of 64 ns period is OK. (period of 274 s)
		*/
		seq += ktime_get_real().tv64;
		seq += ktime_get_real().tv64 >> 6;
		#if 0
		printk("init_seq(%lx, %lx, %d, %d) = %d\n",
		saddr, daddr, sport, dport, seq);

Admin message