From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 14:14:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9145716A4CE for ; Mon, 28 Feb 2005 14:14:52 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5CE43D5A for ; Mon, 28 Feb 2005 14:14:48 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 978683700F; Mon, 28 Feb 2005 09:14:30 -0500 (EST) To: Mike Silbersack In-reply-to: Your message of "Mon, 28 Feb 2005 03:30:01 CST." <20050228032537.H11576@odysseus.silby.com> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Mon, 28 Feb 2005 09:14:30 -0500 From: Roland Dowdeswell Message-Id: <20050228141430.978683700F@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: Ashwin Chandra Subject: Re: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 14:14:52 -0000 On 1109583001 seconds since the Beginning of the UNIX epoch Mike Silbersack wrote: > >If you're sure that the program is a forkbomb, why not modify the forkbomb >protection that is already present in kern_fork.c: > >tsleep(&forksleep, PUSER, "fork", hz / 2); > >What it does at present is whenever you try to fork and you've hit your >process limit (see limits(1)), it puts your process to sleep for .5 >seconds. If you have a better way to tell if something is a forkbomb, why >not just do the same thing, perhaps with a shorter sleep. > >Don't try too hard to defeat forkbombs, though. Whenever it's been >discussed, someone has invariably pointed out that you could just fork 750 >processes, and then have those 750 do something else which is kernel >intensive, like reading/writing 1 byte at a time. Also be careful of unintended consequences. When it was suggested that we import this tsleep fork-bomb protection into NetBSD, I mentioned that it would cause pathological behaviour in certain well behaved applications. E.g. thttpd. Thttpd is an event driven web server which performs quite well. It does need to fork to process CGI scripts, though. If it hits the process limit and is put to sleep then it will stop serving static web pages---certainly not the desired behaviour. I.e. a perfectly reasonably running web server will quickly fall to its knees if a few too many CGIs were requested. There is no way to solve the problem, too, because thttpd cannot know reliably whether it can fork before it tries to. I think that we ended up putting in this ``fork-bomb protection'' conditionally with the default of off. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/