Hi,
On Mon, Mar 27, 2000 at 07:51:45AM -0800, Kaz Kylheku wrote:
> >
> > This is part of a kernel defence mechanism, and yes, it is important to
> > do something like this. If you don't, then a user can create a fork-
> > bomb task which continually forks off children, and if the children and
> > parent all keep the same credits, then it becomes essentially
> > impossible for any other process ever to get scheduled. It is a _nasty_
> > denial-of-service attack, and that's why the kernel has to share the
> > scheduling credits out when you fork.
>
> So what you are saying is that we effectively have that behavior which is
> called ``process scope scheduling'' for threads.
Not at all --- separate threads are scheduled entirely independently.
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.
--Stephen
-
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:20 EST