Re: Cache coherency, clustering, and Kernel virtualization

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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