From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 04:55:42 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 B59F016A4CE for ; Mon, 28 Feb 2005 04:55:42 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.46.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D0D043D46 for ; Mon, 28 Feb 2005 04:55:42 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.135]) by smtp.ucla.edu (8.13.2/8.13.2) with ESMTP id j1S4tgBb003467 for ; Sun, 27 Feb 2005 20:55:42 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j1S4tfts017154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 27 Feb 2005 20:55:41 -0800 Message-ID: <000c01c51d51$ce6243b0$abe243a4@ash> From: "Ashwin Chandra" To: Date: Sun, 27 Feb 2005 20:56:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0 X-Scanned-By: smtp.ucla.edu on 169.232.46.136 Subject: Fw: 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 04:55:42 -0000 The forkbomb program I wrote is just one parent that forks 750 or so children that each malloc around 40 MB's of memory and do a mem traversal through it. The children do not fork. I see the overhead of forking could be causing this, but shouldn't there be some difference in the load of the system when each forkbomb process is set to the lowest priority? To fork 750 processes would incur overhead until those processes are created (Which shouldnt take much of real time) and once they are running, if they other processes that have already been created are running "nicely", I don't see why there is so much overhead too. Do you recommend anotoher way to solve this forkbomb problem and keep the system DoS free for others? Ash > ----- Original Message ----- > From: "Coleman Kane" > To: "Ashwin Chandra" > Cc: > Sent: Sunday, February 27, 2005 7:28 PM > Subject: Re: Priority Increasing > > >> Well, since the program is running a forkbomb, it is gonna stress out >> the kernel. The kernel is constantly creating new process spaces, as >> well as filling in the queue. >> >> Are we talking a O(2^n) forkbomb here (where the forks also fork)? >> Remember, there is overhead associated with forking off new processes, >> and if your program is doing it continuously, nicing them is not going >> to fix the problem. I suggest you fix the program so that it doesn't >> forkbomb. >> >> You can also rlimit it, and force the number of processes to a >> specific ceiling. This will result in crashing the program everytime >> you hit that limit, however. Try looking into djb's daemontools if you >> want to duct-tape it (ports/sysutils/daemontools) >> >> -- >> coleman >> >> On Sun, 27 Feb 2005 18:11:57 -0800, Ashwin Chandra >> wrote: >>> Hi all, >>> Ive been trying to counter the malicious effects of a forkbomb by >>> setting the forkbomb parent and children to a PRI_MAX priority, although >>> this is not having any effect on the system load. >>> >>> Basically in my code when I know which process is acting maliciously >>> (forkbomb), I run the following simple code: >>> >>> FOREACH_KSEGRP_IN_PROC(p, kg) >>> { >>> printf("old prio:%d", kg->kg_user_pri); >>> kg->kg_user_pri = PRI_MAX; >>> printf(" new prio:%d", kg->kg_user_pri); >>> } >>> >>> When it prints out, the old prio was 180 and the new gets set to 255 >>> although there is help to the system...the system is still under stress. >>> Do you guys know any good ways of hacking the scheduler to make a >>> process that is bad run MUCH MUCH less as to not overload the system? >>> >>> Ash >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >