Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2000 19:46:09 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, Brett Glass <brett@lariat.org>, security@FreeBSD.ORG
Subject:   Re: stream.c worst-case kernel paths
Message-ID:  <20000121194609.A19536@fw.wintelcom.net>
In-Reply-To: <200001212353.PAA64927@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 03:53:28PM -0800
References:  <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew Dillon <dillon@apollo.backplane.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000121194609.A19536>