fork bomb

The fork bomb generates a large number of its own copies and thereby tries to fill the free space in the list of active processes of the operating system . After filling out the list of processes, it becomes impossible to start a useful program. Even if any other process stops working and the place in the list of processes becomes free, the start of a useful program is unlikely, since many other copies of the fork bomb are already waiting for the opportunity to launch their next copy.

In addition to filling out the list of processes, strategies for filling virtual memory, processor time, sockets, and other system resources are also possible. Exhaustion of these resources results in a slowdown or practically shutdown of the operating system and / or useful programs (computer freezing ).

Fork bomb can be obtained as a result of an error in good programming. For example, a program listening on a network port may, upon receiving a network packet or establishing a connection, fall into an endless loop of creating its own copies to process a packet or connection. A simple programming error can lead to a memory leak or to consequences that are characteristic of the results of the fork bomb.

C : ^[1]

  #include <stdlib.h> 

 int main ( void )
 {
     for (;;) {
         system ( "start" );
     }
 }

Bash : ^[2]

  : () { : |  : & } ;  :

Perl :

  fork while fork

Python :

  import os
 
 while True :
     os .  fork ()

Ruby :

  fork while fork

The second option:

  loop { fork }

PHP :

  <? php

 while ( true ) {
     pcntl_fork ();
 }

Microsoft Windows batch file :

  : s
 start % 0
 goto : s

Second option

  start % 0 % 0

VB.NET Option

  Do System .  Diagnostics  Process .  Start ( System . Reflection . Assembly . GetExecutingAssembly (). Location ) Loop While True

Go :

  package main

 func main () {
	 for {
		 go bomb ()
	 }
 }

 func bomb () {
	 go bomb ()
 }

Pseudocode :

  alg ProgramX
 bye truth
    nts
       Call ProgramX
    kts
 con al ProgramX

In the event of a successful operation of the fork bomb, it becomes difficult or practically impossible to restore the computer to normal operation without rebooting , since the only way to stop the fork bomb is to simultaneously stop all working copies of the fork bomb. In most operating system implementations, calling a command to terminate a process requires starting a new process, which is impossible under conditions of a successful fork bomb.

However, in practice, some fork bombs do not require such drastic measures and can be destroyed without the need for a reboot. Consider, for example, the case of the bomb from the example above:

  : () { : |  : & } ;  :

The peculiarity of this code is that it does not go in cycles after an unsuccessful generation of its copies, but terminates. As a result, the list of processes is constantly on the verge of filling: one of the copies of the fork bomb is completed, and the vacated space immediately engages in the newly created process from another copy of the fork bomb. It becomes possible to compete with the fork bomb to capture a place on the process list. Then it is possible, sooner or later, to launch a command to destroy all copies of the bomb bomb at the same time, or to launch a safe program that will gradually “win back” a place in the process list until the last fork bomb process is completed. An example of such a secure zsh program:

  while ( sleep 100 & ! ) do ;  done

One way to prevent the negative effects of fork bombs is to force a limit on the number of processes that the user can start at the same time. The amount of virtual memory allocated and other system resources may also be limited. When the maximum available processes has been exhausted, an attempt by the process to create a new process will fail. The maximum of processes to be launched should be such that it allows you to run a reasonable useful number of programs, but does not lead to a system crash while simultaneously launching a fork bomb from all users of the system.

It should be noted that limiting the number of processes in itself does not prevent the launch of the fork bomb, but is only aimed at minimizing the possible harm in case of its operation.

Another solution to the problem is the intelligent recognition of fork bombs using the operating system itself, but this solution has not been widely used.

There is such a difficulty that if a fork bomb takes up all available processor time, then the results of its operation can be disastrous not only on a single-processor, but also on a multiprocessor system, even if the number of processes is limited. For example, if the number of processors is 16, and the maximum number of running processes is 100, then on each processor there will be an average of 6-7 working instances of the fork bomb devouring processor time. To solve this problem, a restriction on binding to processors is applied.

• fork () - system call of Unix-like operating systems (according to the POSIX standard)
• Zombies and orphan processes - similar cases of leaking system resources