Re vkernel and all

[Matthew Dillon]

: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.
:
:Best regards
:   Oliver

    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
    jails.

    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.

						-Matt