[ On Thursday, December 5, 2002 at 13:18:22 (-0500), Roland Dowdeswell wrote: ]
> Subject: Re: Fork bomb protection patch 
>
> I'd say that I still don't believe that this rather contrived case
> calls for such a hack being put into the kernel, though.  I mean,
> consider why we might want to do this:
> 
> 	1.  to prevent malicious local DOS attack,
> 	2.  to prevent accidental local DOS, or
> 	3.  to keep up with the Joneses.
> 
> Obviously with (1) this is going to make no real difference because
> something like:
> 
> 	for (;;) {
> 		while (fork()!=-1)
> 			;
> 		for (i=0; i<SOME_BIG_NUM; i++)
> 			getpid();
> 	}
> 
> Will have a similar effect.

for even more fun allocate as much memory as possible in each process
and modify one bit/byte/word of at least one different page of it
between every getpid() call! ;-)


>[[....]]   As an aside I'm currently
> running a fork bomb on my workstation and admittedly X is a tad
> jump and periodically my mp3 player skips, but it is not like I
> can't finish this email...

Exactly.  (That's a very good demonstration, BTW!)


> There is some credence to the argument for preventing (2)

No, I don't think so, at least not with such a horrendously bad hack as
a forced sleep.  The proper solutions are waiting in the wings for
anyone who really wants to solve _that_ problem in some decent way.


> I can't help but think that there is a larger issue here which
> should be solved in a more general way, though.

I don't think there's anything that needs changing other than the first
two points on the patch that started this thread.

This problem was well recognized about the time UNIX Seventh Edition was
publically released, if not before, and it was clearly documented in the
V7 manuals.  By the time I first tried the trivial version of the attack
(rom the manual) on a PDP-11/60 running V7 (about 1982, IIRC) there was
already a patch that prevented a crash and which allowed one keystroke
on my part to terminate the whole mess.  Everyone in the terminal room
complained that the system seemed slower than normal, but no damage was
done.  Had I done it during "prime time" and been caught by the admins
I'm sure they would have been able to clean it up had I not stopped it
first.

What's still the best solution to this issue was provided by *BSD around
about 4.0, if not in 3.9, and we still have it today, but now with even
easier ways to manage it and with the greater experience that has come
with time and use.

The best work-around for situations where it happens anyway was
originally the one reserved process slot.  The addition of 9 more
reserved slots, plus the use of ratecheck() to avoid spamming the
console, makes this work-around viable and sufficient in modern systems
with less ingenious admins than those who dealt with this same problem
with only one reserved process slot.

People who won't utilize the available solutions, and who complain about
any some tiny amount of sluggishness when they fork-bomb their own
systems, or whey whine about their own inability to figure out what's
happening when someone else does it to them, really do not get even one
tiny bit of my sympathy.


> I'm not sure if I can properly address (3).

Me neither -- but that is definitely the root of the problem as I see it.....

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>