Re: fork bomb:the come back

Marcin Dalecki (dalecki@dacotec.net)
Mon, 27 Dec 1999 09:36:58 +0100


usjew99@my-deja.com wrote:
>
> I want to talk about couple lines of c (or any
> language) code that brought down my Red Hat6.1
> linux2.2.12-20 system.
> #include
> #include
> void main(){
> for(;;){fork();}
> }
> Yes it is a dead loop that consumes all the system
> resources and brings the whole system down.
> The tragic thing is i tested it in root and user
> mode same effect: no response from the keyboard is
> accepted, only power off/on can help.
> Even more tragic thing is that this problem been
> known for years and nobody done anything to
> prevent it.

Let me guess: You are using a setup where the swap
space resides on a different (IDE?) disk then the
main system? At least this is the setup where I can reproduce
the same problem.

> If it is possible to bring system down, crash,
> freeze it. The system is insecure and unstable.

Give me a sledge hammer and I will almost instantly
show you that nearly every system out there is unstable
and insecure (from physical treatment... ;-).

> Using the opportunity to ask isn't it possible to
> prevent bad programs from being buffer overloaded.

No it almost isn't without an *huge* performance penalty
on common processor architecutres. There are reasons
why IBM for one is making good money on MVM and such...

> Kernel should be able to check, before moving
> memory, the size of the buffer and only that part
> of the memory that fits in to buffer will be put
> in it, any left overs will be discarded.

The kernel isn't the problem here.

> I’m not a big programmer so no fixes or patches,
> but this issues are very important. So i think big
> shot as Linus may fix them.
> The good OS such as linux should be able protect
> itself and everything else such as users and other
> programs from "bad" written programs. You can't
> just say "oh, that program is badly written so it
> was buffer overloaded." But its not the program
> that moves memory in to small buffer, its only
> asks kernel to do it. So kernel should be able to
> check the buffer, Kernel suppose to be the good
> guy.

Paparlapap.... apparently you don't quite understand the
issues involved. The problem are not values returned from
the kernel, but the values feed to the kernel. Along the lines
of for example exec("#!/bin/myfavoriteshell"); The stack
smash is happenning entierly inside userland before such a call.
The test you are requesting would require AI on the side
of the kernel for parameter semantics checking.

--Marcin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/