folks,

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.

[requirements for multiple Objectmemories in one squeak process]
- Each ObjectMemory would have an eden space, survivor spaces, old 
space segments, a large space, a fixed space, a compiled code cache and 
a stack space.
- The memory layout, in squeak's heap, would have a partition table 
referencing these objectMemories, and they wouldn't overlap in the heap.
- Each would be garbage collected separately and have all appropriate 
GC agents.
- The only limit to the number and size of these objectMemories will be 
available memory, a limit to the total overhaed cost and optimizing the 
success of QoS constraints.
- Out pointers and in pointers between objectMemories would be 
implemented using a vm implementation of the EventualSend references 
(found at http://minnow.cc.gatech.edu/squeak/2410).
- An optimization to asynchronous eventual sending would be to 
immediately evaluate message invocations and resolve the promises to 
references.

[questions and comments]
1) What problems or difficulties would there be in allowing 
ObjectMemory to be multiply instantiated?
2) How would the interpreter need to be changed for allocation?
3) How would the interpreter need to be changed for collection?
4) What would need to be the stack representation of partitioned 
references?
5) Do you think this is an interesting direction of research in squeak?

cheers,
robert


squeaker maxim:
A small hack can fix a small problem
A big problem is really many small problems
Hack the image! 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2302 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030125/c98156ee/attachment.bin