From owner-freebsd-security Fri Jan 21 19:22:41 2000 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F1BBA1563C for ; Fri, 21 Jan 2000 19:22:32 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id TAA28591; Fri, 21 Jan 2000 19:46:09 -0800 (PST) Date: Fri, 21 Jan 2000 19:46:09 -0800 From: Alfred Perlstein To: Matthew Dillon Cc: Poul-Henning Kamp , Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121194609.A19536@fw.wintelcom.net> References: <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200001212353.PAA64927@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 03:53:28PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Dillon [000121 17:08] wrote: > :> It may be worth doing this sort of patch after the release, but if the goal > :> of the release is to fix bugs then the proper solution is to use the one that > :> we know already makes a difference - restricting the output path. > : > :And you conveniently forgot to quote the one line of my email where I > :said as much. > : > :-- > :Poul-Henning Kamp FreeBSD coreteam member > :phk@FreeBSD.ORG "Real hackers run -current on their laptop." > > Sorry about that. I'm freaking out a little because we are too damn close > to release to be making any big changes to the network stack and protocols. > Frankly, big changes are not necessary. A corrupted packet is less likely to contain valid data that would match up against our internal state. I'm not planning on committing such work until after the 4.0 split, however I don't see why we should spend the time to checksum 10 megabytes per second _in an interrupt routine_ when we could easily do so right before inserting it into the socket after its contents have been validated. Please look at tcp_input, notice the "goto drop" and "goto dropwithreset" jumps, they are scattered throught and after some pretty close examination (no tests yet) I've been able to see that we can signifigantly move the tcp checksum farther into the path. Another problem is that we may _have_ to do a checksum so as to drop invalid packets instead of RST'ing them, however once we reach our threshold of rate limiting we can avoid the checksum because at that point we aren't sending RSTs, there's no point in differentiating between corrupted and invalid packets. This is a lot less complicated than it sounds. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message