Re: CVS commit: src/tests/net/icmp

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Sun Jul 11 2010 at 16:49:59 +0200, Jean-Yves Migeon wrote:
> On 11.07.2010 15:00, Antti Kantee wrote:
> > On Sat Jul 10 2010 at 12:30:07 +0200, Adam Hamsik wrote:
> > Given that the idea of jails/zones is to limit a userspace process,
> > doing this in a userspace process is not the obvious route.  It probably
> > could be done with a software-isolated process, but we are desperately
> > "not there" with our toolchain.  Another choice would be to port rumpuser
> > on top of the Xen hypervisor interface, like jym recently envisioned.
> 
> Let me get a bit more precise here :) the purpose is not to offer
> container-like virtualization, but rather to have a finer grained
> approach, close to microkernels, with small processes/tasks that perform
> a specific functionality. What I would like to do is to get rid of the
> "big dom0 uber-privileged" domain that you encounter in hypervisor-based
> virtualization, by having smaller, isolated domains that perform
> specific tasks (one for block device access, another for network, device
> driver, so on). Without requiring to integrate
> yet_another_monolithic_yet_modular_linux_kernel in.

I didn't mean to say you suggested to offer virtualization containers.
Sorry.  I merely intended to say you had the desire of using the Xen
hypercall interface.  Although I must say now I understand more clearly
why you wanted to do that.

> Frankly, I have no idea how this would perform; basically, dom0 can be
> considered as one big uber-privileged domain, which is as critical as
> the hypervisor itself; if it crashes, or gets compromised, the system is
> entirely crippled. Purpose is to avoid a contamination of the whole dom0
> context if only one of its part is buggy, and one requirement is to get
> it as small as possible.

"perform"?  Are you using that term for execution speed, or was it
accidentally bundled with the rest of the paragraph?

> > Even so, rump is about virtualizing the kernel, not the user interface
> > layer.  Given that jails/zones is a well-understood technology with at
> > least some sort of NetBSD implementation already done, why not go the
> > obvious route and finish that off?
> 
> I think he was referring to using a rump kernel as a "syscall proxy
> server" rather than having in-kernel virtualization like jails/zones.
> 
> That would make sense, you already have proxy-like feature with rump.

I'm not so sure.  That would require a lot of "kernel help" to make
everything work correctly.  The first example is mmap: you run into it
pretty fast when you start work on a syscall server ;)

That's not to say there is not synergy.  For example, a jail networking
stack virtualized this way would avoid having to go over all the code, and
"reboot" would be as simple as kill $serverpid.  Plus, more obviously,
it would not require every jail to share the same code, i.e. you can
have text optimized in various ways for various applications.