Re: [RFC] Virtualization steps

[Nick Piggin <nickpiggin@yahoo.com.au>]

Eric W. Biederman wrote:

> Nick Piggin <nickpiggin@yahoo.com.au> writes:
>
>
> > I don't think I could give a complete answer...
> > I guess it could be stated as the increase in the complexity of
> > the rest of the code for someone who doesn't know anything about
> > the virtualization implementation.
> >
> > Completely non intrusive is something like 2 extra function calls
> > to/from generic code, changes to data structures are transparent
> > (or have simple wrappers), and there is no shared locking or data
> > with the rest of the kernel. And it goes up from there.
> >
> > Anyway I'm far from qualified... I just hope that with all the
> > work you guys are putting in that you'll be able to justify it ;)
>
> As I have been able to survey the work, the most common case
> is replacing a global variable with a variable we lookup via
> current.
>
> That plus using the security module infrastructure you can
> implement the semantics pretty in a straight forward manner.
>
> The only really intrusive part is that because we tickle the
> code differently we see a different set of problems.  Such
> as the mess that is the proc and sysctl code, and the lack of
> good resource limits.
>
> But none of that is inherent to the problem it is just when
> you use the kernel harder and have more untrusted users you
> see a different set of problems.

Yes... about that; if/when namespaces get into the kernel, you guys
are going to start pushing all sorts of per-container resource
control, right? Or will you be happy to leave most of that to VMs?

--

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/