forget I said anything about all those separate ObjectMemories.  :)

cheers,
rob

On Sunday, January 26, 2003, at 11:54 AM, Mark S. Miller wrote:

> At 06:13 AM 1/26/2003 Sunday, Stephen Pair wrote:
>
>> I think it's important to think in terms of capabilities, not 
>> segmenting
>> the image and such.
>
> Yes.
>
>> The system really needs to be redesigned from the
>> ground up to take capability based security into account.
>
> Yes. It's a pleasure to see this acknowledged.
>
>> There are a
>> couple of things that we need before we can actually tackle it
>> however...
>
> Many of these things are already provided by the Kernel-E virtual 
> machine
> design. Those that aren't already provided by Kernel-E are probably 
> needed
> by Kernel-E as well. So I hereby officially (whatever the hell that can
> possibly mean) propose the Kernel-E virtual machine design as a 
> starting
> point on this "from the ground up" vm design, to be jointly evolved as 
> we
> realize fundamental features that it should have to meet our 
> respective goals.
>
> Note that I am not proposing either the current JVM-based Kernel-E
> implementation or the nascent C++-based implementation, nor the 
> current E
> syntax nor libraries. I am proposing Kernel-E as a design and as a VM 
> spec,
> to be re-implemented out of the material of the Squeak virtual 
> machine's
> implementation.
>
> This can and should start out as an implementation of Kernel-E in 
> Squeak,
> but this is just a development step that leaves Kernel-E in the same 
> kind of
> second-class status that it currently has on the JVM. Instead, I hope 
> to see
> the Squeak vm interface and the Kernel-E vm interface both supported
> alongside each other and sitting on top of the same object memory, gc,
> method dispatch, and execution mechanisms.
>
> The purpose of preserving the Squeak vm interface is to run those old
> non-capability-based Squeak libraries until we can afford to replace 
> them.
> Until then, I propose we also create a taming mechanism and move it 
> into the
> implementation, to sit "between" the two virtual machines. The main 
> thing
> this means is that a Smalltalk behavior has two method dispatch 
> tables: one
> as seen from Smalltalk, and another as seen from Kernel-E. This avoid 
> the
> "proxy object" overhead.
>
> The result need not be E. E is defined not just by Kernel-E but by a 
> C-like
> surface syntax and by a set of standard sort-of-Java-like libraries,
> sometimes inherited (via taming) from Java. Instead, you can build a
> Squeak-like language on the Kernel-E vm, with a Squeak-like syntax and 
> feel,
> and with Squeak-like libraries, many of which will start out as 
> tamings of
> existing Squeak libraries. Perhaps this is what the "Squeak-E" project
> becomes, so perhaps this is what we should call the resulting language.
>
> This direction is radical and expensive, but I believe something like 
> it is
> approximately the least radical one that works well enough to be worth
> doing. At Electric Communities we painfully went through three 
> different
> attempts to turn the almost-capability-secure Java into a 
> capability-secure
> system. The other approaches (including the island-like one) seemed 
> easier
> but turned out to be harder or impossible.
>
> The main problem on my end with making this proposal is the terribly
> inadequate state of the Kernel-E documentation. If you guys find this
> direction appealing, I will flesh out the docs on an as-needed basis 
> so that
> we can continue to evaluate this proposal.
>
>
>> we need a good meta object protocol that will enable an object
>> to protect direct access to it's state (i.e. #instVarAt:put: and 
>> friends
>> should be usable only indirectly through some reflection object).
>
> Kernel-E has a "meta.scope()" (Would be "meta scope" in Squeak-E 
> syntax)
> expression that's inspired by, among other things, the Smalltalk
> "thisContext". Like "thisContext", "meta" is a keyword. "meta.scope()"
> evaluates to a map (ie, a Dictionary) mapping in-scope variable names 
> to
> their corresponding Slot objects (reified value-holding variables).
>
> The in-scope variables include all lexically visible variables up to 
> the
> containing object boundary, then the instance variables (the variables 
> used
> freely by the innermost containing object), then the outer variables. 
> It
> contains no more than this in order to allow the garbage collector to 
> gc
> obviously not needed variable values.
>
> There needs to be a corresponding "meta.<something>" expression for
> accessing the Kernel-E AST of any of the lexically enclosing object
> definition expressions. This AST serves a role in Kernel-E like class 
> or
> behavior does in Smalltalk.
>
>
>>  The
>> MOP also needs to enable any object to fully replicate the protocol of
>> another object...which would probably require both delegation and the
>> ability to provide custome message responders (overriding the normal
>> message lookup).
>
> I don't understand this.
>
>
>>  We also need to re-design the current meta model from
>> the ground up (allowing for name spaces, environment, etc).
>
> Yes. Please look at Kernel-E.
>
>
>> Then, objects could provide façades that offer more restricted
>> capabilities and which would prevent any direct access to the façade's
>> state (i.e. the underlying object reference).
>
> Trivial in Kernel-E.
>
>
>> The VM would probably also need some way of enclosing object 
>> references
>> in some sort of cryptographically secure envelope that would enable 
>> only
>> the designated recipient to access the object reference.
>
> Kernel-E has nothing like this, and the need has never come up. What 
> do you
> have in mind?
>
>
>> Once you have these foundations in place, then you could conceivably
>> design a system where capabilities are protected by controlling object
>> references.  Each "door" that is "unlocked" in the system would expose
>> some set of capabilities by opening up access to some set of objects.
>
> A good image.
>
>> I imagine that using this system, you could even design a processor
>> scheduling system that would be resilient to denial of service types 
>> of
>> attack.
>
> That's where vats should come in. You can't usefully reify resource 
> use at
> the granularity of the individual object, and shared memory 
> multi-threading
> is an unmitigated disaster. You can and should put vats on a resource 
> budget
> of both time and space. See KeyKOS's and EROS's Meters, Schedules, and 
> Space
> Banks for principled ways to do this. It can indeed solve many denial 
> of
> service problems.
>
> Fortunately, this is one of the rare security issues that can be 
> postponed
> without painting yourself into a corner. E currently postpones this.
>
>
>> I think http://erights.org/ has some good information on this topic.
>
> Thanks!  Hopefully my posts here can help provide a bridge.
>
>
> ----------------------------------------
> Text by me above is hereby placed in the public domain
>
>         Cheers,
>         --MarkM
>
>