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
>