Cache coherency, clustering, and Kernel virtualization

[Matthew Dillon]

:Virtualization serves as a crude but effective way to accomplish the
:former, but not the latter. That a constrained subprogram should not be
:allowed to adversely affect its container is important -- indeed it is
:something that we should be able to take for granted these days. But to
:use the existence of such a capability to justify the underengineering
:of the security of the systems which run beneath; is disconcerting, to
:the say the least.
:
:I am not opposed to the concept of allowing the kernel to run in
:userland or of virtualization generally. It would great for a BSD
:to finally have that capability. But it doesn't make it okay to allow
:vulnerabilities in any system -- virtualized or otherwise, clustered or
:otherwise. If your clustered system is not something that you could
:trust as your main OS, I would think twice about deploying any such
:system to a public network.
:
:-Eric

    I wouldn't call it crude.  I would call it effective.

    There is a very simple way to think about security in a software system.
    It is simply:  The less code you have running outside your security
    abstraction(s), the more secure your system is.  That's it.

    A user process context is a black box.  Nothing inside it can get out
    except through a page fault, trap, or system call.  The page fault,
    trap, or system call represent choke points.  If all the real kernel
    does is take those choke points and pass the data to the virtual kernel
    instead of trying to process it, then the amount of code one must write
    to serve that necessary function is fairly minimal and can arguably be
    made quite secure.

    The virtual kernel running as a user process is another black box, in
    another sandbox.  Since this user process is able to talk to the real
    kernel through hundreds of system calls and code paths, it is 
    considerably less secure -- not much more secure then a normal user
    process running as NON-root would be, but still considerably more
    secure then allowing the related services to run under the real kernel.
    From the point of view of the real kernel we now only need to audit
    a single program, the virtual kernel, to protect ourselves from it and
    everything running under it.  Securing a single program is arguably far
    easier then securing the ten different services that have been
    virtualized under that program.

    Consider the types of security failures we see out in the field... nearly
    all such failures exploit code bugs that allow a security barrier to
    be breached.  For example, a system call might have a bug that allows
    an unprivilaged program to write to kernel memory.  An encryption
    algorithm might have a buffer overflow.  A JVM's byte code interpreter
    might have a bug that allows a java program to break out of its sandbox.
    An external API might not properly check arguments passed to its
    functions.  It is nearly impossible to secure millions of lines of code.
    It is far easier, however, to lock those million lines of code into
    a sandbox and secure the choke points that lead out of the sandbox.

    There is no way around this basic truth.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>