Date: Wed, 11 Jul 2001 01:32:54 -0500 From: Alfred Perlstein <bright@sneakerz.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: "Robert E. Lee" <rel@gulbransen.com>, Dag-Erling Smorgrav <des@ofug.org>, Ted Mittelstaedt <tedm@toybox.placo.com>, js43064n@pace.edu, freebsd-security@FreeBSD.ORG Subject: Re: Kernel Panic Message-ID: <20010711013254.F1894@sneakerz.org> In-Reply-To: <200107110605.f6B657X24415@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Jul 10, 2001 at 11:05:07PM -0700 References: <xzp4rt57sjq.fsf@flood.ping.uio.no> <Pine.BSF.4.33.0107102047420.261-100000@rlee.leefam.org> <20010710230329.A1894@sneakerz.org> <200107110605.f6B657X24415@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010711 01:05] wrote: > > :It'd be almost trivial to limit the amount of outstanding IO on a > :per uid basis. Have time for a patch? :) > : > :Hint: > :store the amount of IO in the uidinfo struct, if you go out of > :bounds, sleep on the outstanding buf counter address for a short > :time (*), if the user completes IO, then issue a wakeup. > : > :(*) the reason you can not sleep inifinitely is because you may cause > :a deadlock situation against yourself when writing out dirty buffers, > :or maybe not.. ? > : > :Anyhow, that should allow for throttling. > : > :-- > :-Alfred Perlstein [alfred@freebsd.org] > > Appropriate resource limits and a properly configured system can go a > long way towards preventing a crash. Expecting an untuned, > insufficiently endowed machine to be able to handle a DOS attack from > a shell prompt is unrealistic. The machine can't really tell the > difference between something like the above and, say, someone starting > up a copy of gnome, or mozilla, or ircd, or a user account dedicated to > serving cvsup. You certainly can't tell by looking at the I/O load... > the above script would only max out the disk's seeking (which a lot > of programs can do), and it does not actually represent any significant > amount of I/O bandwidth relative to, say, a program copying a large > file. > > So the fix is really nothing more then the sysadmin setting > appropriate resource limits, monitoring the machine, and blowing away > any idiot user who does the above. The fix is certainly not to try > to make the OS magically figure out that someone is running a DOS > attack from a shell prompt and having it arbitrarily throttle the > uid! I totally agree that 'rmuser' is quite often the best fix for problems such as this. It still would be nice to be able to throttle IO on a large multiuser system for those that need it. A large sequential IO should be serviced faster than a wide seeking IO so that it shouldn't penalize people doing sequential too badly. Anyhow, this would really just be to implement a QoS type solution for large multiuser systems, it would not be enabled by default, in fact it probably would have to fall under some compilation option if implemented. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? 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?20010711013254.F1894>