[Devel] [PATCH rh7] cgroups: Drop virtualization code, v4

[Vladimir Davydov]

On Thu, May 07, 2015 at 01:29:59PM +0300, Cyrill Gorcunov wrote:
> On Thu, May 07, 2015 at 01:17:27PM +0300, Vladimir Davydov wrote:
> > > We're creating cgroups for container on ve0 but bindmount them
> > > from inside of container, thus on userspace level (via config file)
> > > we can setup which cgroups are allowed for use. Still we're not
> > > limiting anyhow creating new sub-cgroups (via mkdir) inside
> > > container, and this one should be performance penalty mainly
> > > (new cgroup allocation is done via direct kzalloc without
> > >  any memory limits as far as I understart).
> > 
> > Actually, it is accounted to memcg, just like any kmalloc, but the
> > problem isn't that we miss accounting. The problem is that the more
> 
> I see, it's deep inside of slab/slub code, thanks.
> 
> > features we allow to use from inside a container, the more different
> > types of kernel objects a container can create, the more potential
> > security issues we have. E.g. on reclaim the kernel walks over all
> > memory cgroups, as a result a container user can try to DOS the node by
> > creating thousands of cgroups.
> 
> So maybe we should limit the number of nested cgroups in container?
> There is root->number_of_cgroups maybe we should setup some limit
> on ve config.

The more parameters we have the worse. What should be a default value
for this? 10, 50, 100? And why? Can we guarantee that the user of a
container won't be able to exploit the system with this particular
number of cgroups? Can we be sure that this particular number of cgroups
will be enough? I don't think so.

If something goes wrong, one can disable cgroups in a container
altogether, otherwise he has to take the risk.