DragonFly kernel List (threaded) for 2006-09
Re: Cache coherency, clustering, and Kernel virtualization
Eric Jacobs wrote:
On Sat, 2 Sep 2006 11:49:36 -0700 (PDT)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
Now consider the problem of tying an entire kernel into an internet-based
cluster. Does that sound like something that would be 'safe' to
integrate into your real kernel? NO WAY! It is virtually impossible
to 'secure' a kernel which is operating as a single system image in
a cluster of machines connected together via the internet.
There are two, distinct security issues pertinent here. The first is the
ability of a supervisory program (like the kernel) to partition its
resources to other programs such that they cannot interfere with each
other nor with the supervisor itself. The second is the ability for the
subsystems so constrained to maintain their own integrity -- to act in
accordance with the policy that the owners of those subsystems set in
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.
Hmm... take a look at the evolution and far from trouble-free history of, to
name just one, z/MV.
The issue is neither new, nor lacking more than a few mechanisms that address it.
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.
I don't see where Matt's approach should be expected to introduce any greater
vulnerability, nor any less effective enforcement of 'manners', than otherwise
Seem to me that even on 'day one', it would be more secure / secure-able, than
many other tools in the F/OSS arena - or at least no less so.
And I've 'cracked' those mainframes (white-hat, guys, in-house white-hat! - with
my family name one dares nothing else!)...
'Big Iron' historical techniques - IBM or otherwise, can be instructive.
But absent control over CPU hardware and instruction set, certainly not a
Great place to learn what *didn't* work, and why. No use repeating mistakes.