linux-kernel - A long overdue fork-bomb defense ?! (idea + psuedocode, no patch yet)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Sun, 9 Apr 2017 17:04:04 -0500
From:   Robert Hailey <forkbomb@...dok.com>
To:     linux-kernel@...r.kernel.org
Subject: A long overdue fork-bomb defense ?! (idea + psuedocode, no patch
 yet)

Another fork bomb thread? Didn't we decide in the 90's that the answer
was "configure process limits" or "if it was solvable surly a solution
would have been found by now"?

Somewhat continuing from:
https://lkml.org/lkml/2011/4/8/275
...but a more refined idea and psuedocode.

ASAICS I have "the ultimate solution to fork bombs"... the synopsis:
* When we run out of process table space, clear the worst offenders,
and erect a "wall" in the forkbomb's cgroup for the rest of the fork
bomb to hurriedly run into and die a horrible death.

But the efficacy of one's own ideas are hard to judge, so I would
appreciate anyone smarter than me either:
* pointing out how horribly wrong I am, or
* helping flesh out the idea into a patch or proof-of-concept that it
might be tested

... otherwise my lack of c-language skill and kernel experience might
make this languish for years to come until anything actually comes of
this.

If you interested, of course, psuedocode is here it is for your
dissection:

* http://osndok.com/pubfiles/forkbomb-patch.html

If it is more appropriate to dump the psuedocode into the email thread,
I can do that instead... I don't know what is preferred.

Thanks in advance.

--
Robert Hailey

(Non-subscriber, please CC me in responses)