Re: [RFC] Virtualization steps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric W. Biederman wrote:

Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux