Date: Mon, 28 Feb 2005 03:30:01 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Ashwin Chandra <ashcs@ucla.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Priority Increasing Message-ID: <20050228032537.H11576@odysseus.silby.com> In-Reply-To: <000801c51d3a$e1ac47c0$abe243a4@ash> References: <000801c51d3a$e1ac47c0$abe243a4@ash>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Feb 2005, Ashwin Chandra wrote: > Hi all, Ive been trying to counter the malicious effects of a forkbomb > by setting the forkbomb parent and children to a PRI_MAX priority, > although this is not having any effect on the system load. > > Basically in my code when I know which process is acting maliciously > (forkbomb), I run the following simple code: If you're sure that the program is a forkbomb, why not modify the forkbomb protection that is already present in kern_fork.c: tsleep(&forksleep, PUSER, "fork", hz / 2); What it does at present is whenever you try to fork and you've hit your process limit (see limits(1)), it puts your process to sleep for .5 seconds. If you have a better way to tell if something is a forkbomb, why not just do the same thing, perhaps with a shorter sleep. Don't try too hard to defeat forkbombs, though. Whenever it's been discussed, someone has invariably pointed out that you could just fork 750 processes, and then have those 750 do something else which is kernel intensive, like reading/writing 1 byte at a time. In other words, limiting the maximum number of processes a user can have must be part of the equation - and we probably set that limit too high by default. :) Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050228032537.H11576>