Date: Sat, 22 Jan 2000 19:06:26 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Brett Glass <brett@lariat.org>, Don Lewis <Don.Lewis@tsc.tdk.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Re[2]: explanation and code for stream.c issues Message-ID: <200001230306.TAA18458@salsa.gv.tsc.tdk.com> In-Reply-To: <4.2.2.20000122083929.01a5aa90@localhost> References: <Vladimir Dubrovin <vlad@sandy.ru> <4.2.2.20000122083929.01a5aa90@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 22, 8:52am, Brett Glass wrote: } Subject: Re: Re[2]: explanation and code for stream.c issues } True. But y'know, he does have a point. Shouldn't tcp_input() drop } or reject anything with certain combinations of flags really early on? } } About 15 years ago (has it been that long?) I wrote part of a TCP/IP } stack for a class at Stanford. The first statement in the routine } which was the equivalent of tcp_input() checksummed the packet. } The second one was a "case" (this was Pascal) that broke out } cases for every combination of the TCP option flags. (The } compiler implemented case statements as jump tables, so this } was fast.) } } Do you think it's worth doing that here, both for clarity and } for speed? It would probably help to catch all the issues involving } option flags, and it would be more efficient than the current } structure (which does lots of tests one at a time and is harder to } follow). The current code was written for speed rather than for clarity and tries to optimize the most commonly used path through the code. In the old days, CPUs were slow. Today, contemplate gigabit Ethernet ... I suspect that if you try to implement this as a big switch, you'll end up with either a lot of duplicate code or a bunch of gotos, and a lot of what happens depends at least as much on the state of the connection. Don't forget that the SYN and FIN bits can be trimmed off if they fall outside the window. RST is more of a unique case, but even it needs to pass sequence checks that depend on the state of the connection. I'm wondering if it might make more sense to generate IPv4 and IPv6 version unique versions of the code from a common m4 or cpp ancestor rather than to fill the code with a mass of ifdefs and inline protocol version tests. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001230306.TAA18458>