linux-kernel - Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <xr93d38g77w5.fsf@gthelen.mtv.corp.google.com>
Date:	Tue, 13 Mar 2012 10:00:58 -0700
From:	Greg Thelen <gthelen@...gle.com>
To:	Glauber Costa <glommer@...allels.com>
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Suleiman Souhlal <ssouhlal@...eBSD.org>,
	<cgroups@...r.kernel.org>, <suleiman@...gle.com>,
	<penberg@...nel.org>, <cl@...ux.com>, <yinghan@...gle.com>,
	<hughd@...gle.com>, <peterz@...radead.org>,
	<dan.magenheimer@...cle.com>, <hannes@...xchg.org>,
	<mgorman@...e.de>, <James.Bottomley@...senPartnership.com>,
	<linux-mm@...ck.org>, <devel@...nvz.org>,
	<linux-kernel@...r.kernel.org>, rientjes@...gle.com
Subject: Re: [PATCH v2 02/13] memcg: Kernel memory accounting infrastructure.

Glauber Costa <glommer@...allels.com> writes:
> 2) For the kernel itself, we are mostly concerned that a malicious container may
> pin into memory big amounts of kernel memory which is, ultimately,
> unreclaimable. In particular, with overcommit allowed scenarios, you can fill
> the whole physical memory (or at least a significant part) with those objects,
> well beyond your softlimit allowance, making the creation of further containers
> impossible.
> With user memory, you can reclaim the cgroup back to its place. With kernel
> memory, you can't.

In overcommit situations the page allocator starts failing even though
memcg page can charge pages.  When page allocations fail the oom killer
plays a role.  Page allocations can fail even without malicious usage of
kernel memory (e.g. lots of mlock or anon without swap can fill a
machine).  I assume that the kernel memory pinned the malicious
containers will be freed or at least become reclaimable once the
processes in malicious containers are killed (oom or otherwise).  We
have been making use of the oom killer to save a system from
irreconcilable overcommit situations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/