netdev - Re: [RFC] per-containers tcp buffer limitation

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 25 Aug 2011 15:11:37 -0300
From:	Glauber Costa <glommer@...allels.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	Chris Friesen <chris.friesen@...band.com>,
	Daniel Wagner <wagi@...om.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Linux Containers <containers@...ts.osdl.org>,
	<netdev@...r.kernel.org>, David Miller <davem@...emloft.net>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [RFC] per-containers tcp buffer limitation

On 08/25/2011 12:44 PM, Stephen Hemminger wrote:
> You seem to have forgotten the work of your forefathers. When appealing
> to history you must understand it first.
>
> What about using netfilter (with extensions)? We already have iptables
> module to match on uid or gid. It wouldn't be hard to extend this to
> other bits of meta data like originating and target containers.
>
> You could also use this to restrict access to ports and hosts on
> a per container basis.
>

Hello Stephen,

I am pretty sure netfilter can provide us with amazing functionality 
that will help our containers implementation a lot.

I don't think, however, that memory limitation belongs in there. First 
of all, IIRC, we are not dropping packets, re-routing, dealing with any
low level characteristic, etc. We're just controlling buffer size. This 
seems orthogonal to the work of netfilter.

Think for instance, in the soft limit: When we hit it, we enter a memory 
pressure scenario. How would netfilter handle that?

So I guess cgroup is still better suited for this very specific task we 
have in mind here. For most of the others, I have no doubt that 
netfilter would come handy.

Thanks for your time!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html