Date: Tue, 25 Jan 2000 10:22:58 -0700 From: Warner Losh <imp@village.org> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Re: Merged patches Message-ID: <200001251722.KAA04527@harmony.village.org> In-Reply-To: Your message of "Tue, 25 Jan 2000 10:09:32 MST." <4.2.2.20000125095042.01a5aba0@localhost> References: <4.2.2.20000125095042.01a5aba0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4.2.2.20000125095042.01a5aba0@localhost> Brett Glass writes: : This is a very, VERY concervative patch. As such, it : doesn't include rate limiting of RSTs independently of : ICMP_BANDLIM (which is really a different beast -- on : a router, you might NOT want to limit ICMP but want to : limit bandwidth). THat's the point. Yes, it is a conservative patch, but we're 4 days from code freeze. *NOTHING* is going to be radical at this point. : The patch also does not prevent a : non-SYN packet from matching a listening socket (this : condition is caught later, but piecemeal with many : individual tests; the coverage isn't comprehensive). : And it does not shield the entire TCP stack from : sending or receiving multicast packets -- just this : path. It's still possible to emit a TCP packet with : a multicast source or destination address after : this patch. The source addresses of packets are still : tested to see if they're muticast addresses in MANY : places instead of in one place.... It seems to : me that it pays to use a flag in the mbuf (as is : done with B_CAST) to centralize the test. (A new : flag called, say, SRC_B_CAST would do this. There's : room in the flag word.) By what code paths is this possible? Please be specific. : Also, in at least one place (maybe more), the code does : multiple tests of the TCP option flags in succession. : Several tests of this kind should generally be merged : into a switch for speed (the many conditional jumps : cause pipeline stalls on many processors, especially : older ones) and readability. It does? If so, it certainly doesn't ADD them. : In short, I'd only go with this patch as-is if my : purpose were to minimize the changes made before : release. If this were the goal, I'd go back to the : code immediately thereafter and try to tackle some : of the inefficiencies and holes in this key input : path more aggressively. Yes. That's exactly the goal. Like I said in my initial mail, I may remove the ICMP_BANDLIM option as an option, but bump the rate limiter to 1000. But that's about as far as I'd be willing to go at this time. Warner 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?200001251722.KAA04527>