Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Mark S. Miller [mailto:markm@caplet.com]
> Sent: Friday, July 07, 2000 11:00 AM
> To: Karp, Alan
> Cc: 'e-lang@eros-os.org'
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 			(snip)
> 
>   All objects in the same vat as A that also have a live 
> reference to B share 
> this RemoteRef.  There's a lot of information per RemoteRef, 
> in order to 
> manage the message pipelining of live messages sent over this 
> reference.  
> However, none of this is persistent information.  The only 
> remote references 
> that survive a checkpoint/crash/revive are SturdyRefs, 
> covered above.  The 
> persistent encoding of a RemoteRef merely need be adequate to 
> restore a 
> broken reference on revival, since a revival implies a 
> network partition, 
> and a network partition also causes RemoteRefs to become broken.

We do something similar in e-speak Beta 2.2.  Before a remote resource can
be used, I need a repository entry on my local machine.  All references to
this remote object are through names bound to its repository handle.  The
target of requests to this resource, its handler, is a proxy that talks over
the wire.  One difference is that the repository reference can survive a
network partition if that's the policy in effect.  

Normally, the proxy will go away when it loses connection to the other
machine.  This step automatically makes the resources it owns inaccessible,
and a scavenger will eventually remove their entries from the repository.
However, there are times when two machines being connected is the norm, such
as the two machines on my desk.  In this case, we can save the expense of
rebuilding the environment by keeping the state in the repository.  Any
access attempted while the connection is broken gets an exception, but as
soon as the connection is restored, everything works.

>
>			(small snip)
> 
> >  (I hate statistical uniqueness unless you
> >tell me what happens in the case of a collision.  It 
> shouldn't happen in the
> >life of the Universe, but nothing says it won't.  A more 
> serious problem is
> >the various flaws in the system, including human error.  But 
> this topic is
> >for another discussion.)  
> 
> For security among mutually suspicious parties on open 
> networks, in the 
> absence of any one universally trusted third party, the only 
> known means of 
> trustable interaction is cryptography.  Cryptography depends on the 
> statistical uniqueness of private keys (or other secret 
> information).  Any 
> cryptographic proposal must be examined wrt the consequences 
> of key theft.  
> A collision will seem like an undetected case of key theft.

This explanation is acceptable and basically the same one Nigel Edwards gave
me when I raised the issue about SPKI.  Calculations of the unlikeliness of
collisions, on the other hand, do nothing for me.  E-speak Beta 2.2 limited
its dependence on statistical uniqueness to the initial authentication of
the user.  After that, everything was deterministic.

> 
>			(snip)
> 
> >I presume that the object handle is encoded in
> >this name, so it can be wildcarded, but I don't know what it means to
> >wildcard the handle to a general object.
> 
> As Jonathan mentioned, E itself has no notion of wildcarding. 
>  Further, an E 
> object reference is totally opaque to the E programmer, so there's no 
> ability to aggregate objects based on any internal structure of the 
> reference's representation.  The one case of this that would be both 
> possible and meaningful is to aggregate objects based on 
> their hosting vat.
> 

When I create capabilities, I need a way to refer to the objects they
control.  These references can, of course, be object handles, but you've got
to get started somewhere.  That's where names come in.  I'd want to use
wildcards when I want a single capability to control access to a set of
objects that have names related to each other in some structured way.

> 
> >Clearly, the Vat needs a mapping between the object and its 
> identifier in
> >the capability.  My understanding is that the mapping is 
> encoded in the
> >identifier.  However, the designation could also be an entry 
> into a table
> >kept in the Vat.  This table would differ from the e-speak 
> repository in the
> >information associated with the object, and the capabilities would be
> >cryptographically secure.  However, the principle is the same.
> 
> Actually, the association between a SwissNumber and the 
> object it designates 
> is via a table in the vat, and is used to dereference all 
> references that 
> use the SwissNumber representation.  Without this table, 
> these reference 
> representations by themselves are insufficient to determine 
> what object is 
> designated.  So, in one sense, we are doing what you suggest. 
>  However, we 
> make no use of the flexibility this table provides -- we use 
> it only as an 
> effectively immutable mapping between SwissNumbers and 
> designated objects.  
> If these techniques would indeed add value to E, it seems we 
> already have 
> the data structures necessary to support them.
> 

We should talk.

> 
>          Cheers,
>          --MarkM
> 

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278