[vm][q] what's needed to support multiple, disjoint
Mark S. Miller
markm at caplet.com
Sun Jan 26 03:38:52 UTC 2003
At 01:04 PM 1/25/2003 Saturday, Robert Withers wrote:
>I am trying to think what facilities we could build that generates the most
>secure squeak environment. After a lot of reading, my approach has been to
>create special object references, partition them, and modify the way they
>react to message sending. Other complimentary approaches establish filtered
>method-dictionaries, at the meta-level. I believe these two approaches will
>start to integrate.
>In focusing on reference partitioning, a minimalist implementation would be
>vm-supported partitioning. To really ensure that two different secured
>areas (vats) don't leak in undetectable ways, I believe that the capability
>to instantiate multiple instances of ObjectMemory is the most effective.
Because of the current scarcity of my time, I have not read this thread --
only skimmed -- and so would not normally jump in and criticize until I
understood what I was criticizing. However, I sense y'all may be going into
a rathole that I'd really like to see you avoid. The Squeak VM is already
close enough to being a perfect capability machine that you should be able
to succeed, and it would be a terrible shame for you not to get there.
Lesson #1 from the E experience:
POLA is best when practiced at finest grain.
Put another way, the kernel-supported protection domain should be the
individual object, meaning that cooperation without vulnerability should be
supported well at the granularity of individual object interactions.
Further, the libraries should be built around this mutual suspicion assumption.
Lex Spoon's and Anthony Hannan's work, in order to be as upward compatible
from existing Squeak code and practices as possible, coarsens the grain of
separate trust domains substantially (eg, into islands). I think this is
unfortunate, but may be a good beachhead in order to start somewhere and
evolve towards finer grain. In any case, it is a compromise whose benefits
are clear and whose costs are not clearly fatal. It's not clearly fatal as a
starting point for evolution because, at the level of kernel-foundational
rules, the boundaries between protection domains are still just object
boundaries, and the interactions across these boundaries are just regular
object messages. But you must eventually get rid of mutable class variables,
rather than trying to rescue them, before you transform Squeak programmers
into natural capability programmers. Likewise for all other global/static
Rob's suggestion has two parts. One is to introduce new kinds of references
to support the E concurrency control model. I think that would be great, and
should be discussed separately. The other is to introduce separate object
address spaces as protection domains, whose space would be separately
allocated. This may be inspired by the E vat, which we should understand
has the following properties:
Vat boundaries have very little security-significance in E. For virtually
all security-reasoning purposes, one reasons about the E object-reference
graph at object granularity without taking vat boundaries into account. (The
main way these are taken into account is explained at
Vats are important boundaries for reasoning about concurrency, persistence,
partition and recovery, and resource control. Vats are also the units of
preemptive destruction. All these have some security significance, but very
little compared to the significance of objects.
In any case, if the granularity of supported mutually suspicious interaction
were coarsened to something vat-like (or address-space-like, or
process-like), you may as well be using C to write domain-code for a
capability OS. You would no longer be turning Squeak into a capability
language, and you would lose the benefits.
I write in a hurry. If I have misunderstood anyone terribly, which is
quite possible, my apologies.
Text by me above is hereby placed in the public domain
More information about the Squeak-dev