DragonFly BSD
DragonFly kernel List (threaded) for 2006-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Cache coherency, clustering, and Kernel virtualization


From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Sun, 03 Sep 2006 09:43:48 +0800

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

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.

-Eric

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


Au Contraire.

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 'template'.

Great place to learn what *didn't* work, and why. No use repeating mistakes.

Bill






[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]