For most of my working life I have dealt with system failure. To understand failure in systems we need to understand weakness, we tend to call most of these weaknesses vulnerabilities. All systems are vulnerable one way or another. One of the most interesting is inherent vulnerability.

Enter the Fork Bomb :(){ :|:& };:

Since 1979 there has been a fundamental (inherent) vulnerability in all Unix type operating systems. The operating system allows a process to start other processes, this is called forking. The command above creates a process, which creates a process, which creates a process, which creates a process… you get the idea. CPU depletion is only minutes away and the system shuts down. Usually, when we spot a vulnerability we say “Wow that’s bad, let’s get rid of it”. We have various mitigations for vulnerabilities including removing the offending function.

Today if you go and buy a Raspberry Pi, install Ubuntu or login to your TV or home router  and type this command, after a couple of minutes everything stops working. You don’t even need to have elevated privileges like root to execute the command. So what gives? Why does this still happen when we have known about it for years?

There are a few reasons but it comes down to the fact that to remove it would fundamentally change the way the operating system functions. In fact, forking is good, useful and helpful. No one has any plans to redesign this.

To mitigate the fork bomb without fundamentally changing the very nature of the operating system we manually put limits where we can. This ensuring that these ‘race conditions’ do not occur. But we have to be careful in putting limits in place as there is a fine line between choking functionality and exposing vulnerability. Additionally, systems will be used for different applications, each have their own requirements, one size does not fit all. The mitigation is called ‘ulimit’ and as system designers we apply this setting with care. Ulimit is not a setting that by default on most systems.

God uses our vulnerabilities instead of fundamentally removing them

Each of us has a gift, a beautiful, powerful contribution to life. As we are born into a broken world this gift is vulnerable. God built you just the way you are for a reason, all the functions you can perform were created good and for Gods purposes. You are beautiful. You are beautiful and vulnerable at the same time. If God removed the vulnerability he would also remove the beauty.

The great SysAdmin

If we are all honest we know we have these vulnerabilities, but they seem so intrinsically tied to who we are. Enter the great SysAdmin of life, the Holy Spirit. He not only has the business requirements (Gods Plan) but also our design criteria. He knows you inside and out, every piece of code. The Holy Spirit helps us in our weakness [Rom8:26]. Without God our vulnerability is exposed and the fork bomb can lead you into a race condition. We succumb to all the issues that plague us as broken vulnerable people. This causes CPU depletion, a place of loneliness, frustration, addiction or emptiness, our system has run-out.

For our functionality to be where God uses our beauty for His glory, we need the designer of the system to place the ulimit to His advantage. He has designed us as a cohesive system. He knows our vulnerabilities better than we do. Allowing God to use our weakness for His strength [2 Cor 12:9–10] means allowing Him to mitigate our vulnerabilities. This is evident in what has been termed the ‘Lords Prayer’ [Matt 6:13] Or as Dallas Willard paraphrases

“Please don’t put us through trials, But deliver us from everything bad”
Please configure my ulimit, Mitigate my vulnerabilities
When we grasp the fact that God loves us, with our vulnerabilities and that this is a gateway to His great strength. We can start, with the help of the great SysAdmin to live with confidence that no fork bomb the enemy drops will bring system failure.

Categories: Code

Leave a Reply

Your email address will not be published. Required fields are marked *