Date: Sat, 22 Jan 2000 19:12:25 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Don Lewis <Don.Lewis@tsc.tdk.com>, Brett Glass <brett@lariat.org> Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Re[2]: explanation and code for stream.c issues Message-ID: <200001230312.TAA18497@salsa.gv.tsc.tdk.com> In-Reply-To: <200001230306.TAA18458@salsa.gv.tsc.tdk.com> References: <Vladimir Dubrovin <vlad@sandy.ru> <4.2.2.20000122083929.01a5aa90@localhost> <200001230306.TAA18458@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
We really should move this conversation from -security to -net. Followups to -net, only. On Jan 22, 7:06pm, Don Lewis wrote: } Subject: Re: Re[2]: explanation and code for stream.c issues } 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?200001230312.TAA18497>