From owner-freebsd-security Fri Jan 21 18:47:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id B90E8157C0 for ; Fri, 21 Jan 2000 18:47:49 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id SAA17045; Fri, 21 Jan 2000 18:47:29 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id SAA52680; Fri, 21 Jan 2000 18:47:28 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id SAA15469; Fri, 21 Jan 2000 18:47:28 -0800 (PST) Message-Id: <200001220247.SAA15469@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 18:47:27 -0800 In-Reply-To: Wes Peters "Re: stream.c worst-case kernel paths" (Jan 21, 7:19pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Poul-Henning Kamp Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , Alfred Perlstein , Brett Glass , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 7:19pm, Wes Peters wrote: } Subject: Re: stream.c worst-case kernel paths } Poul-Henning Kamp wrote: } > } > In message <200001212311.PAA64559@apollo.backplane.com>, Matthew Dillon writes: } > } > > No, this is far too dangerous. If a packet is bad due to being } > > corrupted then you want to throw it away (via the checksum check) } > > *BEFORE* you start messing around with the socket state. Otherwise } > > a perfectly legitimate packet that got corrupted in transit may } > > cause a disconnect or other failure. } > } > It makes a lot of sense to do cheap (relative to the checksum) } > checks on the packet before we do the checksum, as long as we } > don't modify any state before the checksum is validated. } > } > If it is cheaper to try to locate the pcb, than to calculate the } > checksum, the locate the pcb first and drop the packet before } > doing the checksum. } } Except you may get a false match on a garbled packet, that just happened } to get garbled to match a different connection. The checksum is done } first to avoid such situations. Until the packet has been verified good, } none of the data in it can be trusted. It shouldn't matter if you skip the checksum on any path that doesn't affect the connection state and does a "goto drop". This really doesn't matter, though, if the machine is configured with enough CPU to handle valid packets at wire speed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message