From owner-freebsd-security Fri Jan 21 20: 2:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0A0DA155AC for ; Fri, 21 Jan 2000 20:02:34 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id VAA28764; Fri, 21 Jan 2000 21:02:14 -0700 (MST) Message-Id: <4.2.2.20000121205951.01a58bb0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 21:02:11 -0700 To: Alfred Perlstein , Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Poul-Henning Kamp , security@FreeBSD.ORG In-Reply-To: <20000121194609.A19536@fw.wintelcom.net> References: <200001212353.PAA64927@apollo.backplane.com> <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:46 PM 1/21/2000 , Alfred Perlstein wrote: >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. One of the first things the routine does is look for a socket that matches the TCP header. This relies on the port numbers and control bits, which are covered by the checksum. This is the hard limit on how long you can defer the checksum. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message