netdev - Re: [PATCH] [net-next] tcp: avoid sending zero TSval

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:	Tue, 01 Sep 2009 18:16:06 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	opurdila@...acom.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] [net-next] tcp: avoid sending zero TSval

From: Octavian Purdila <opurdila@...acom.com>
Date: Mon, 31 Aug 2009 20:44:56 +0300

> Per RFC1323, zero TSecr is considered invalid. Thus we must avoid when
> possible sending a zero TSval.
> 
> Currently, we use the least significant 32 bits of jiffies to fill in
> TSval. But that can wrap around to zero (in 5 minutes after reboot,
> and every 49 days after that in the worst case).
> 
> This patch approximate a wrap-around zero TSval to 1. This is better
> then emitting a value which will be ignored.
> 
> Signed-off-by: Octavian Purdila <opurdila@...acom.com>

Ok, I've changed my mind again.  I think we need to go with
a solution like this.

Even if we could somehow justify allowing zero timestamps,
I just checked some other stacks and all of them ignore zero
tsecr values.  So we can't make that kind of change no matter
what.

This patch needs some changes.

We have to adjust the tests we make against tsecr.

If we bump up a zero jiffies to one in an advertised timestamp,
then we get back a tsecr value of one, and jiffies is still
zero, we should use a comparison value of one not zero.

This is not trivial.  You might think it's OK to handle all of
this by just adjusting the definition of tcp_time_stamp but that
gets used by a lot of other things in the stack so those side
effects need to be analyzed.

Grepping around also shows that we also have some code that doesn't
handle jiffies wraparound at all, f.e. check out the rcv_tsecr tests
in net/ipv4/tcp_lp.c :-/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html