Date: Mon, 13 Sep 1999 20:02:50 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) Message-ID: <Pine.OSF.4.05.9909131942360.7389-100000@oracle.dsuper.net> In-Reply-To: <199909130336.UAA20252@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
!> I think that what needs to be done is to split the problem in two. First, !> allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT !> is used, it simply means 'try harder, sleeping a bit if necessary'. This !> requires ensuring that all the networking code deal with the failure !> case - a time consuming but straightforward task. If a failure occurs, !> one simply drops the packet, not the connection or anything else drastic. !> just the packet. Yes, these is mainly the part I've been working on recently. The sleeping and what not (as I'm sure you've seen from the patches if you looked at them) has already been completed. Adding a counter that will expire and return a pre-defined error is trivial, in this case. The only real issue here (if we can call it that) is get _all_ the networking code to recognize this. Anyone want to help? :-) !> !> The second problem that needs to be addressed is resource exhaustion. !> For example, allocating thousands of connections and socket-opting their !> buffers as large as possible, or programs such as syslog accepting new !> connections ad-infinitum. This is a harder problem to fix properly, !> but a lot of the various issues such as those with syslog can be dealt !> with in userland rather then the kernel. !> !> -Matt !> I agree. The issue here is somewhat related (if I understand your explanation correctly) to [local] processes attempting to grab a lot of socket buffer space. I was a little less concerned with this issue since, as I previously mentionned, Brian Feldman is working on limiting socket buffer space. Nonetheless, if we do not consider limiting, here's what I believe will need to be done: As explained above, when we run out of mbufs and/or mbuf clusters (and some are needed), if we are M_WAIT (when processes socket opt their buffers as large as possible, the call is usually with M_WAIT), we will end up tsleep()ing for certain periods of time, until our counter expires and we return our pre-defined error (as mentionned above). When we do return this error, however, the caller (for instance, we can consider sosend() the caller -- which, if I remember correctly, is one of the callers to MGET() when we setsockopt a large buffer and consequently write() to this socket), will also have to know how to properly deal with this error (e.g.: kill the process?). Killing the process may seem somewhat sadistic to some ( :-) ), but remember that if we do get to the point where 'normal' local processes eat up so much buffer space that we run out, we should probably be increasing NMBCLUSTERS and/or maxusers anyway. As for script weenies, I hope that Brian (and whomever else may be working on it) gets that sockbuf limiting code done, because, to be quite honest, I don't think that script kids having to comprimise more than one account just so they can DoS a box will be much of an issue (if worse comes to worse, we can limit per gid -as opposed to per uid). With exhaustion attacks such as these, we're better off just limiting. Regards, Bosko Milekic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9909131942360.7389-100000>