OSDev.org

We can crash any multitasking operating system such as Linux or Windows easily with a tiny program by recursive program loading. Pseudo code for myprogram.exe: When program runs, computer begins to slow down and crashes.
I think there is no way to prevent it even in Modern operating systems.
What are your opinions to prevent it?

Congratulations for re-inventing the fork bomb.

There are also various approaches like grsecurity that allow the kernel to do resource management: No more than X processes per user, no more than Y forks per minute per user, you get the idea. Not that difficult, actually.

XenOS wrote:Congratulations for re-inventing the fork bomb.

I don't know this.

Solar wrote:There are also various approaches like grsecurity that allow the kernel to do resource management: No more than X processes per user, no more than Y forks per minute per user, you get the idea. Not that difficult, actually.

But why these approaches are not used by windows or linux?

Read the man page on "ulimit".

Solar wrote:There are also various approaches like grsecurity that allow the kernel to do resource management

muazzam wrote:But why these approaches are not used by windows or linux?

The posted link wrote:grsecurity is a set of patches for the Linux kernel

It might help if you try and read - or possibly practice your english a bit more if you miss even the basic information presented to you.

That program doesn't crash the operating system. It does the expected: Making a bunch of processes until it fails. Then it keeps trying but likely failing.

This is not a bug in the OS, it is merely a denial of service attack, and a poor one. You can limit memory usage per user if they are meant to share, or just bill users appropriately for their memory usage.

Actually, Fork bomb was new term for me.

Going through grsecurity's features and configuration options is generally a good idea if you are thinking about "securing" your OS. There are many very good ideas in there; many of them impacting performance, of course.

I'm coming up with a permission system for applications in my OS.

One permission will be the ability to launch processes.

Another permission will be the ability to execute when it's window is unfocused.

You need to explicit grant an application those permissions (i.e. during install-time). It's not perfect, but it provides a little protection - arbitrary applications can't create processes. If a process if fork-bombing you can just hit the Windows key or something to unfocus it.

I guess my favored solution would be grouping processes into "jobs", where each job has a limited amount of resources (such as memory, CPU time, maybe slots in the process table etc.). When a process which belongs to a job launches a new process, the child process by default becomes a member of the same job. A fork bomb may thus exhaust the resources of the job, but not of the whole system. Another nice feature in this model would be the ability to kill / abort a job as a whole, including all its processes. This would kill all forked processes of the bomb at once, without any chance for them to fill up freed slots by further forking.

You can always make a more clever fork bomb.

How would this work, for example, in the case of jobs as I suggested?

Hi,

XenOS wrote:How would this work, for example, in the case of jobs as I suggested?

Plausible examples may include:

• maybe you tell a CRON daemon to start 5 copies of you in 2 seconds time
• maybe you inject key-presses into the keyboard buffer and "exit()" so that if you were started by something like bash then bash gets those key-presses and starts 2 copies of you as background jobs
• maybe you tell the OS that you're a file system driver for "XYZ file system" and give it a dummy disk image/file (containing several partitions formatted as "XYZ file system") and let the OS auto-mount those file systems (where each of those file systems happen to contain a dummy disk image/file containing more partitions for the OS to auto-mount, which....)
• Maybe you pretend to be a driver for a USB hub (that has many "virtual USB hubs" connected, that each have...)
• Maybe your process is used by Apache (via. CGI) whenever someone asks for the web page "http://localhost/foo.html", where your process asks Apache for the web page "http://localhost/foo.html" itself.
• Maybe it's just a simple trojan thing - e.g. "This game needs fork permission so the client can start a server process for single-player games"
• Maybe there's a way to trick the GUI into thinking that the user clicked on the "OK, let this process have fork permission" button in the dialog box; where the application's installer clicks the button before the user has time to see it

Cheers,

Brendan