DragonFly kernel List (threaded) for 2007-01
Re: Re vkernel and all
:Another use of vkernels is, of course, to build secure
:environments. Just like the jail(2) feature, but with
:an even stronger separation from the host system. I
:think the vkernel feature will be appreciated by people
:who are sufficiently paranoid.
:Of course, a vkernel costs a lot more resources than a
:jail, especially because you have to assign a certain
:amount of RAM to the virtual machine. While you can
:run hundreds of jails at once on a single machine with
:moderate RAM, you probably can run only a dozen vkernels
:(or less) on the same machine, depending on what you
:need to run inside them.
:I'm sure people will find more uses that vkernels.
Yes, performance winds up being a major factor in how a virtual kernel
can be used verses a jail. But it isn't all negative... even though
you can have a lot more of them, jails simply do not work well for
sharing environments. It is still ultra-easy to take down the 'real'
system from a jailed environment, and the complexity of the jail
tests inside the kernel does not fill me with trust as to our my to
secure the jail. It is also extremely easy for one jail to starve the
resources of other jails. Resources cannot easily be partitioned between
A virtualized kernel requires actually reserving the (memory) resources
beforehand, and it also guarentees that there won't be any resource
leakage or starvation. If you give a vkernel 64 MB of ram, that's all
it will use, period. We can even control I/O and network resource
use through a single choke point for each (VKD and VKE). You just
can't do that with a real kernel. Not with so much ease. So even
though performance suffers some, a virtual kernel is capable of
providing guarentees to the customer that a jail cannot. A virtual
kernel can be made immune to cascade failures from events occuring in
other virtual kernels whereas a jailed environment cannot.
It is clear that kernel code development and management of untrusted
third party environments are THE two major uses for a virtual kernel.
Those are precisely the uses that the linux community uses UVM for.
For DragonFly a virtual kernel will also be a major component of the
clustering work... now if I want to provide resources to an internet
based 'cluster' I will be able to do it by creating a virtual kernel
with precisely the resources I want to donate and then connecting it
into the 'cluster' without having to worry about the security of the
rest of my system.
I didn't realize this until now, but the new vmspace_*() system
calls and the new MAP_VPAGETABLE mmap feature alone can be used
to directly (and SAFELY) provide code-execution resources to a cluster.
You don't even have to run a full blown virtual kernel... just use the
new system calls directly on top of the real kernel (just as the virtual
kernel uses them to manage its emulated user process contexts). This
is a big deal... I had been tearing my hair out on and off for two
years trying to figure out how to cluster an execution environment
and now the problem is basically solved!
Expansion beyond these core uses depends on the type of performance
required. Packet routing probably isn't a good match, but a mail
server or a web server could be if you do not need 100% machine
performance. Same goes for any application where 100% machine
performance is not a requirement.