Date: Wed, 26 Dec 2001 15:13:45 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: Randall Stewart <randall@stewart.chicago.il.us> Cc: net@FreeBSD.ORG Subject: Re: m_reclaim and a protocol drain Message-ID: <20011226151345.A19259@technokratis.com> In-Reply-To: <3C29BEF3.611BCAFE@stewart.chicago.il.us>; from randall@stewart.chicago.il.us on Wed, Dec 26, 2001 at 06:13:40AM -0600 References: <3C235866.B063CC7B@stewart.chicago.il.us> <20011221134307.A69233@technokratis.com> <3C29BEF3.611BCAFE@stewart.chicago.il.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 26, 2001 at 06:13:40AM -0600, Randall Stewart wrote: > > > 1) One of the primary things I thought the drain() functions > > > help with is to ward off DOS attacks. > > > > Well, no, not really. They're just there to `help' out in any > > starvation case, really. > > > > This comment facinates me. The reason we made SACK's in SCTP > revokeable is due to the potential DOS attack that someone > can supposedly lauch if you don't allow the stack to revoke. > > I can actually see the reason that Sally made the comments > and had us change it so that SACK's are revokeable. However > you argue to the contrary and I wonder which is correct. > > If you do not allow revoking it is the same as if a protocol > does not hold a drain() fucntion. A attacker could easily > stuff a lot of out-of-order segments at you and thus > fill up all your mbuf's or clusters (in my current testing > case). This would then yeild a DOS since you could no longer > receive any segments and leave you high and dry.... I agree that it is important to drain. I didn't say that it wasn't, but merely that the drain routine in the mbuf code exists to `help out' in the starvation case. Nothing prevents one from calling a specific protocol drain routine explicitly from elsewhere. It is relatively expensive to drain all the protocols for a M_DONTWAIT caller so perhaps if the protocol expects draining to occur in tight situations, we can have the drain routines called from a different context as well (i.e. not only when mbuf allocations fail but also when, for example, something noteworthy occurs in the protocol code). > > > 2) If drivers all use clusters only and clusters can never > > > call a drain() function, does this not leave both TCP and > > > SCTP weak against an attack on the cluster side of the MBUF > > > system? > > > > Well, firstly, all clusters are accompanied by mbufs. Secondly, as > > mentionned above, -CURRENT drains in both cases. > > > > Hmm.. I will look at updating this... That would be very much appreciated. :-) I feel very bad for not doing this myself because I seem to not be tracking -STABLE much these days. But this is totally my fault and if you don't pick it up, feel free to submit a PR and I swear I will force myself to do it. :-) > > What I think you should do in your code is make the calls with > > M_TRYWAIT (what you call M_WAIT) wherever they are possible and only > > call with M_DONTWAIT where it's really not possible to wait. The > > M_TRYWAIT flag does not imply "run slower than M_DONTWAIT," it just > > means "try harder even if it takes a little longer, since we are able to > > block." > > > > A couple of comments here: > > a) There is NO M_TRYWAIT in the 4.3 strain I am working on.. I am > about to upgrade to 4.4. so maybe it will appear there :> Ah, no there is not. But M_TRYWAIT == better name given in -CURRENT to M_WAIT. Basically, they're the same flag and have the same effect, but the name M_TRYWAIT is more descriptive and thus used in -CURRENT (it means "try harder and wait if necessary, but not necessarily forever"). > b) It is NOT my code that I am talking about. The issue is I am > stuffing a LOT of out-of-order segments up the SCTP stack to > get the drain() function called (so I can test it). Nothing > ever calls the drain function and instead we lose packets at > input since the drivers in the ethernet side of things (as you > mention) do a M_DONTWAIT. My code uses M_WAIT wherever it can... > > > Hmm, maybe thats it... I need to somehow activate a condition where > I send a large segment and do a M_WAIT... Probably easier to build > a test ioctl to call the drain function though.. Hm. Well, at any given time we may get a M_WAIT allocation and that would do it. Note, however, that the drain routines _only_ get called when there are *no* more mbufs (in -STABLE) or clusters (in -CURRENT) left. That means that the mb_map has to be starved and that there are no mbufs on the free lists. They do not get called unless there is total starvation. That's why I mentionned above that perhaps it would be worthwhile to have them called from a different context somewhere from the protocol code when/if the protocol feels that they are necessary. > R > > > > If we don't it seems to me the utility of the drain() fucnction is > > > very very limited.. > > > > > > Regards > > > > > > R > > > > > > -- > > > Randall R. Stewart > > > randall@stewart.chicago.il.us 815-342-5222 (cell phone) -- Bosko Milekic bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011226151345.A19259>