From owner-freebsd-stable@FreeBSD.ORG Thu Dec 16 16:56:20 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AABC01065670 for ; Thu, 16 Dec 2010 16:56:20 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 278AF8FC1F for ; Thu, 16 Dec 2010 16:56:19 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oBGGu1Z9096115; Thu, 16 Dec 2010 17:56:16 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oBGGu0ns096112; Thu, 16 Dec 2010 17:56:00 +0100 (CET) (envelope-from olli) Date: Thu, 16 Dec 2010 17:56:00 +0100 (CET) Message-Id: <201012161656.oBGGu0ns096112@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, mamalos@eng.auth.gr In-Reply-To: <4D08DE9C.1060108@eng.auth.gr> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Thu, 16 Dec 2010 17:56:16 +0100 (CET) Cc: Subject: Re: vm.swap_reserved toooooo large? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, mamalos@eng.auth.gr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 16:56:20 -0000 George Mamalakis wrote: > My dmesg shows: > > pid 1732 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) > pid 2227 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) > swap zone exhausted, increase kern.maxswzone > pid 1544 (console-kit-daemon), uid 0, was killed: out of swap space > swap zone exhausted, increase kern.maxswzone > pid 2864 (memory), uid 1001, was killed: out of swap space > swap zone exhausted, increase kern.maxswzone > pid 1676 (gconf-helper), uid 1001, was killed: out of swap space > > where one can see that pid 1544 was killed before 2864, which is the > process that caused all this mess. Yes, I know that I should use limits > so as not to allow such things to happen, but on the other hand, if a > malicious user causes such a situation he/she may gain access to > information through core-dumps on root processes, AND cause DoS attacks. No. First, when the kernel kills processes because it runs out of swap space, it uses SIGKILL which does _not_ cause a core dump to be written. Second, core dumps are always created with permissions 0600, i.e. they are only readable by the owner of the process. Of course, any user who can run a machine out of memory can cause a DoS attack by doing this. That's the reason why resource limits exist. > If it were for me, I would sort all processes based on their memory > consumption, and start by killing those that have the highest value > (top-bottom) that are NOT owned by root (just a thought, without > thinking about it too much), so as to prevent such situations from > happening. It is very non-trivial to find a generic algorithm that kills the "right" process in such a situation. For example, an attacker could start a lot of small processes that allocate memory. That's the reason why an admin should always configure resource limits approprately. The kernel's killing feature should only be regarded as the very last emergency break, which basically exists only to prevent a reboot. If you're interested, you can find the selection algorithm for processes to kill in the vm_pageout_oom() function in src/sys/vm/vm_pageout.c. Basically, it selects the process that consumes the most physical memory (RAM + swap), not counting the virtual size of the process. Also, some processes are excluded, such as system processes and protected processes (cron and sshd, for example). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell