On Thu, 5 Dec 2002, Roland Dowdeswell wrote:

> But, you have the same problem if you have 2000 programs doing:
>
> 	for (;;)
> 		getpid();
>
> or any other system call.  Why should fork(2) be special?  Just
> because there is an old local DOS attack that used it?
>
> If a process or a number of processes can kill the machine just by
> spinning on forks that always fail, then I believe that this
> underlines a more serious issue that should be addressed and not
> papered over.
>
> If consensus is to penalise the offending process, I'd like to put
> forward the notion of just adding a large number to p_estcpu rather
> than tsleeping.  At least then the solution would work within the
> current scheduler to some degree.

Your points are the most interesting ones I've seen in this thread of
discussion (which seems to have degraded pretty quickly.)

The originally proposed solution is simple and effective; it having
those those traits alone makes it useful, but I think some of the claims
of it being elegant are a bit of stretch.  It's a patch job.  It's a bit
of code to address a specific anomaly (fork bombs) which the scheduler
is unable to cope with adequately.  The point you've made is that there
are other such anomalies which are equally detrimental; the patch job,
being specific to the fork bomb problem, doesn't help with these.

Such fixes are fine, even much welcomed if they're going to keep my
systems alive in the face of more common malicious attacks.  But longer
term, depending on how much spackling there's to be done, it might be
interesting to understand the various signature patterns of DoS attacks.
Then we could make the scheduler aware of those patterns of behavior and
it could lower the culprit processes' priorities.

Assuming that someone somewhere hasn't already done this, it might be an
interesting research topic.  I think it'd be wicked cool if NetBSD's
scheduler could be made /that/ smart.

-brian.