linux-kernel - Re: [RFD] Merge task counter into memcg

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] [day] [month] [year] [list]

Message-ID: <4F8EACC0.50204@parallels.com>
Date:	Wed, 18 Apr 2012 09:00:00 -0300
From:	Glauber Costa <glommer@...allels.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Daniel Walsh <dwalsh@...hat.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg

On 04/18/2012 05:10 AM, Frederic Weisbecker wrote:
> 2012/4/18 Frederic Weisbecker<fweisbec@...il.com>:
>> On Tue, Apr 17, 2012 at 08:17:53AM -0700, Tejun Heo wrote:
>>> Hello, Frederic.
>>>
>>> On Thu, Apr 12, 2012 at 06:59:27PM +0200, Frederic Weisbecker wrote:
>>>> I want:
>>>>
>>>> a) to prevent the forkbomb from going far enough to DDOS the machine
>>>> b) to be able to kill that forkbomb once detected, in one go without race
>>>> against concurrent forks.
>>>>
>>>> I think a) can work just fine with kernel stack limiting. I also need
>>>> to be notified about the fact we reached the limit. And b) should
>>>> be feasible with the help of the cgroup freezer.
>>>
>>> kmem allocation fail after reaching the limit which in turn should
>>> fail task creation.  Isn't that the same effect as the task_counter as
>>> implemented?
>>
>> That's it.
>>
>>>
>>>>> Is there anything for which you need to know exactly the number of
>>>>> processes?
>>>>
>>>> No that's really about prevent/kill forkbomb as far as I'm concerned.
>>>
>>> Hmm... so, accounting overhead aside, if the only purpose is
>>> preventing the whole machine being brought down by a fork bomb, kmem
>>> limiting is enough, right?
>>
>> I think so yeah.
>
> But this needs to be a well defined kind of kmem I think. Relying on
> kernel memory
> alone is too general to just protect against forkbombs. Kernel stack,
> OTOH, should be
> a good criteria.

The problem is not it being too general. The problem is it is 
slab-based, and it takes a lot of allocations to fill a slab page. It
is a small object, but you still have one per task. If you set the limit 
too high, it won't help you. If you set it too low, it will harm
other object users.

> But now I'm worrying, do you think this kmem.kernel_stack limitation
> is going to be useful
> for other kind of usecase?

Yes. Ultimately, we want to track as many kinds of kernel memory to 
avoid having one container harming the others. Page tables and stack 
were already briefly discussed, so I think we would get to that 
eventually anyway.
--
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/