> It is only on thread creation that the initial scheduling credits held
> by the parent get split across the two tasks.
>
> The reason for the split is that if you did not do this, then fork()ing
> would result in two processes each with as many credits as the parent
> had before. In a fork bomb attack, one of these processes will run
> until it schedules, but you are then left with a child process that
> still has full credits, and _it_ can then continue the fork-bomb attack.
> For as long as the attack runs, there is always a new child process which
> has as many scheduling credits as the original forking task had, and this
> makes it very hard to get _anything_ else done in the system to combat
> the fork bomb. For example, the resulting process tree is essentially
> unkillable, as it can manage to stay ahead in the scheduler queue of
> anything root is trying to do to repair the damage.
How about keeping track of the rate of thread creation and switching to the
above behaviour only after the rate exceeds a certain limit? After falling
below a second (lower) limit, the old behaviour may be re-established again.
Essentially, the choice of the limits would make it possible then to
distinguish between "letigimate" thread creation, e.g. to handle an incoming
burst of requests on some server, and the "too quick" case.
Olaf Dabrunz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST