Subject: Re: Fork bomb protection patch
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Lord Isildur <mrfusion@uranium.vaxpower.org>
List: tech-kern
Date: 12/06/2002 19:01:54
this is why STOP and KILL are the uncatchable signals...
if the other processes would themselves kill those which have been
stopped, it might make a more robust fork bomb, by slowing down the progress
in stopping them.. but ultimately, it takes less time to send a stop than
it does to figure out that another one has been stopped, and so this
would only slow down the killing of the forkbomb, and not make it immortal.
with sysV unreliable signals, it might be possible.. but in bsd, i think
one would have to look elsewhere... get the processes wedged in some
device i/o where signal delivery is blocked, or something..
isildur
On Fri, 6 Dec 2002, der Mouse wrote:
> > This variant:
> > [...wabbit code...]
> > Might be even more lively.
>
> I once pondered how to build an `unkillable' wabbit. Of course,
> ultimately, there is no such thing. But I was trying to invent
> something that would require a sledgehammer like dropping to ddb to
> deal with. I've never actually tried any of the ideas out, but it
> might be an amusing exercise on a scratch machine. In particular,
> there has to be something to deal with the approach of hitting them
> with SIGSTOP to make them stop forking so you can kill them....
>
> /~\ The ASCII der Mouse
> \ / Ribbon Campaign
> X Against HTML mouse@rodents.montreal.qc.ca
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>