Fork Bomb

[Pype.Clicker]

oh, just to refresh my mind ...

Appache uses pre-forked process, right ? it creates them right at the start and then it use created process ... You could easily arrange the initial tolerance so that those initially-created process doesn't experience too much trouble.

It's not about having 80% CPU time used by a couple of process here: it's about not having +80% CPU time spent in creating new processes ... forking a new process is heavy work, and creating new process everytime is (imho) bad programming practice.

If you want to hog 100% CPU time, just run "for(;;);" and you'll be done on most UNIX systems ...

Just to make things clear, do you guys consider the "fork bomb" as an intentional attack that should be contained or as a user/programmer mistake that should be prevented?

[Crazed123]

It's not about having 80% CPU time used by a couple of process here: it's about not having +80% CPU time spent in creating new processes ... forking a new process is heavy work, and creating new process everytime is (imho) bad programming practice.

If you want to hog 100% CPU time, just run "for(;;);" and you'll be done on most UNIX systems ...

Just ran a for(;;); attack to test your hypothesis. While my CPU usage meter has skyrocketed straight to 100%, everything is still running smoothly. Why? The for-loop-bomb can still only take up its own timeslice; eventually it gets preempted (this is under Linux 2.6, btw) and my other processes run.

Now, when I tried a fork-bomb it really slowed down my system. Why? A fork bomb drops to the operating system level, and you (seemingly) can't preempt the creation of a new process. So fork-bombs take up CPU time far more annoyingly than even an infinitely compute-bound process.

I, personally, consider them genuine attacks. I've never heard of accidentally writing a fork-bomb.

[B.E]

Sorry if this already been sugested(I could not be bothered reading it).

My segestion would be to limit the depth of the process tree, then limit the number of process that a the root process can handle.

[Candy]

Just ran a for(;;); attack to test your hypothesis. While my CPU usage meter has skyrocketed straight to 100%, everything is still running smoothly. Why? The for-loop-bomb can still only take up its own timeslice; eventually it gets preempted (this is under Linux 2.6, btw) and my other processes run.

Now, when I tried a fork-bomb it really slowed down my system. Why? A fork bomb drops to the operating system level, and you (seemingly) can't preempt the creation of a new process. So fork-bombs take up CPU time far more annoyingly than even an infinitely compute-bound process.

Code: Select all

while true; do while true; do cat /dev/zero >/dev/null& done & done

That killed a solaris system for me once. Make it run, wait until you get a slower response (a few seconds) and then try to kill it. Good luck.


Also good luck on making that impossible.

[proxy]

Now, when I tried a fork-bomb it really slowed down my system. Why? A fork bomb drops to the operating system level, and you (seemingly) can't preempt the creation of a new process. So fork-bombs take up CPU time far more annoyingly than even an infinitely compute-bound process.

this is NOT why a fork bomb kills a system much better than an infinite loop in a single program. Here's why.

Imagine the system has 10 processes, all the same priority, round robin scheduling for simplicity.

if one of them decides to maximize its CPU usage, sure the system will run at 100% usage...but, suppose the other 9 decide they have work to do. Your CPU eating program will only use 10% of the available time slices, leaving the other 90% for the work to be done by the "innocent" processes. Thus you are only robbing the system of 10% of it's computing power.

Now when you do a fork bomb, you still have the infinite loop, but you are also introducing new processes each of which will get a time slice.

So suppose it has run until you have 10,000 processes and is still growing exponentially. At this instant, you have 9,991 processes each of which is trying to use 100% of the CPU, the other innocent proccesses only get to run 0.01% of the time, while your infinite loop program is taking up the other 99.99% of the available time slices!

It only gets worse from here. So it's not really the CPU usage directly that causes the lock up, it's the monopolizing of CPU time slices that does the real damage.

proxy

[AWOS]

Now when you do a fork bomb, you still have the infinite loop, but you are also introducing new processes each of which will get a time slice.

Which makes my idea even better -- allocate time slices to root processes only. This way, real fork'ed processes aren't that inconvienced and fork-bombs are controlled. Works both ways. ;D