Priority Increasing

[Mike Silbersack]

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