vm.swap_reserved toooooo large?

Oliver Fromme olli at lurza.secnetix.de
Thu Dec 16 16:56:20 UTC 2010


George Mamalakis <mamalos at eng.auth.gr> 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


More information about the freebsd-stable mailing list