[vm][q] what's needed to support multiple, disjoint ObjectMemories?

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 
mutable state.

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 
http://www.erights.org/elib/capability/ode/ode-protocol.html#subj-aggregate ).

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 mailing list