Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Jan 2016 15:51:17 +0000
From:      Peter Sewell <Peter.Sewell@cl.cam.ac.uk>
To:        "Jonathan T. Looney" <jtl@freebsd.org>
Cc:        Sam Kumar <samkumar99@gmail.com>,  "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org>
Subject:   Re: TCP_HAVERCVDFIN
Message-ID:  <CAHWkzRSvofzDoH-W6kkhr_JexjbWQkfvN5sX-Ws5NPM-_XhYDQ@mail.gmail.com>
In-Reply-To: <D2B685A4.4F28E%jlooney@juniper.net>
References:  <CAGtMfeBWzGAmt2Kq9bejon54xiz%2BHBOEjho1z=NZe_0fqG5Z2g@mail.gmail.com> <D2B685A4.4F28E%jlooney@juniper.net>

next in thread | previous in thread | raw e-mail | index | archive | help
I remember we found something odd about this in our Netsem formal TCP
spec - see item 12 of the "Implementation anomalies" on p. 64 of:
http://www.cl.cam.ac.uk/~pes20/Netsem/tr.pdf, pasted below.

Peter


12. (Protocol bug) States in which we have received a FIN
TCPS_HAVERCVDFIN(s) is defined as:
In the BSD code, the macro
#define TCPS_HAVERCVDFIN(s) ((s) >=3D TCPS_TIME_WAIT)
Clearly, this set of states should also include CLOSE WAIT, LAST ACK
and CLOSING, since we
must have received a FIN segment to enter such a state.
This macro is used three times in the code (in tcp_input.c),
preventing the following from happening
if we believe we have received a FIN :
1. Processing of urgent data (i.e. from segments with the URG flag set).
2. Processing normal data data, and arranging to ACK it.
3. Processing a FIN segment and performing the appropriate state changes.
See deliver in =E2=88=97.

Impact: A consequence of the first of the above is that it is possible
(with suitably
crafted segments) to generate a SIGURG signal from a socket after its
connection has been closed. Data
may also be received by a closing socket. Similarly, extra FIN s will
be processed, causing an ACK to
be emitted and an increment of the sequence number (of course this
will only happen if the peer=E2=80=99s TCP
stack is broken, or malicious).

On 9 January 2016 at 15:11, Jonathan T. Looney <jtl@freebsd.org> wrote:
> On 1/8/16, 4:45 PM, "owner-freebsd-transport@freebsd.org on behalf of Sam
> Kumar" <owner-freebsd-transport@freebsd.org on behalf of
> samkumar99@gmail.com> wrote:
>
>>I am working with the code for the TCP Stack.
>
> Thanks for choosing FreeBSD! :-)
>
>
>>In summary I suspect that the TCPS_HAVERCVDFIN macro needs to be
>>redefined,
>>but I'm not sure whether that is actually the case. I wanted to open a
>>discussion about this to explore whether this is a legitimate issue.
>
> In short, it appears you are correct that the macro name does not match
> the reality of what it checks. This is likely to cause a problem at some
> point, so it is legitimate to suggest it be fixed.
>
> However, this is non-trivial for at least several reasons:
>
> A) Changing this will require thoroughly testing all the impacted code.
> That requires both a thorough conformance-testing suite, as well as
> thorough performance tests (in case the change impacts performance).
> However, I don't think the FreeBSD project itself has such things at the
> moment. (gnn@ might have more to say on this topic. :-) )
>
> B) Even if the code you reference made an erroneous assumption, others ma=
y
> have written other code that assumes the current behavior. Changing the
> current behavior to be "more correct" might impact other code in subtle
> ways. (Hence, the need for testing: see (A).)
>
> C) Even if we can fully qualify that *our* code works correctly after
> changing this, third parties may have extended our system in ways that
> rely on the current behavior. (Hence the need for testing. They "own" tha=
t
> to some extent. But, we owe them some duty to be careful about changing
> basic building blocks they may use.)
>
> D) Changing this may make it harder to port code from other OSs. For
> example, OpenBSD uses the same definition of TCPS_HAVERCVDFIN that we do.
> On the other hand, it looks like NetBSD updated theirs (17 years ago!) to
> something closer to what you suggest. So, porting code from other OSs may
> already be problematic.
>
> Because we now have some level of TCP stack modularity, we *should* be
> able to build a TCP module that does what you suggest and let people try
> it out while maintaining the option to fallback to the main stack if
> things go haywire. However, that is more complicated than I wish it were
> because it currently requires *copying* code rather than just compiling
> the same code a second time. I have a proposal to address that, but need
> to circulate it and get feedback.
>
> In the meantime, we can talk through some of these obstacles and see how
> we want to handle this. We can always define two macros (the old and new
> one) and change the macro usage from the old to the new one as we feel
> comfortable. If there is desire to proceed, I would recommend that as the
> way forward, assuming we can satisfy the testing concerns.
>
> Jonathan
>
>
> _______________________________________________
> freebsd-transport@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-transport
> To unsubscribe, send any mail to "freebsd-transport-unsubscribe@freebsd.o=
rg"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHWkzRSvofzDoH-W6kkhr_JexjbWQkfvN5sX-Ws5NPM-_XhYDQ>