[E-Lang] Re: E questions

[Mark S. Miller]

At 02:31 PM Friday 7/6/01, Mark S. Miller wrote:
>While that's true, something finer grain would have been preferred if it 
>could be made to work.  As in all such matters, my original model for how I 
>wanted this to operate (and my model for how I want inter-vat debugging to 
>operate) is based on how KeyKOS does it.  In some fundamental sense, I 
>believe, Norm and those guys came up with the right thing for reconciling 
>security (including confinement) with debugging and maintenance of the 
>viability of a system of persistent computation.  I recommend taking a good 
>look at it.
>[...] The short form is that debugging 
>access to the data representation of remote objects will be done much like 
>the Brand-based synergy in KeyKOS to rights-amplify a Start key into a 
>Domain key.

At 08:58 PM Friday 7/6/01, Norman Hardy wrote:
>I describe our hard-nosed attitude towards debugging with abstraction in place here:
><http://cap-lore.com/CapTheory/KK/Debug.html>.

Great!  That page by Norm says exactly what I had in mind with my mysterious 
references.

To apply these concepts to E, let's say that I've remotely constructed some 
objects, A and B, in Norm's vat, and that these are built to be openable by 
a CanOpener C I've also created in Norm's vat.  Let's assume Norm isn't 
willing to make his vat as a whole vulnerable to me -- so I can't do 
vat-level debugging on Norm's vat.  At t0 I am remotely holding the C and A. 
Using rights amplification, I can use C to "open" A, but not B, since I 
don't currently have B, and not any objects in Norm's vat that I may 
reference, but which I don't have opening rights to.  

To "open" A is to obtain a facet on A's state that gives "full" access to 
this state -- a debugger's eye view on A's data.  "full" means, as much 
access as A has.  The access given to A is determined partially by examining 
A's code -- A is only given access to the variables it actually references 
(uses freely).  (I don't currently know of other such restrictions we may 
want to compile in.  Anyone?)

Of course, I can only do data-level debugging of A.  Unlike KeyKOS, I can't 
do control flow debugging for the reasons previously explained.

In E, the (not yet implemented) "confined" auditor guarantees that an object 
is transitively immutable. If A is audited to be transitively immutable, 
then all its state variables (instance variables / variables used freely / 
variables "closed over") must be final variables whose value-guard allows 
only objects that pass the "confined" guard.  (The "confined" guard is the 
same object as the "confined" auditor.  As a guard, it allows instances of 
code it audited, as well as primitive data deemed confined by the TCB, such 
as 33.)  As something that passes the "confined" guard, A corresponds to a 
KeyKOS factory, and the objects it makes to a Factory yield.

Given that all the instances variable of a confined object as so declared, 
and that the data-debugger's eye view gives no access in excess of that 
given to the object itself, data-debugger-level access to A cannot enable 
A's confinement property to be violated.

As for objects made by A, if they're made to be opened by the same can 
opener, then of those object, I can only open those to which I've been I've 
been given access.  This preserves the implied confinement for those objects 
(the "yield") made by the "confined" object A.

We have not yet designed what the protocol is of the can opener, the means 
of building an object to be openable by one, nor the synergy protocol by 
which a can opener opens (or fails to open) a candidate object.  Suggestions 
appreciated!

        Cheers,
        --MarkM