From: "Karp, Alan" <>
Date: Wed, 4 Dec 2002 16:55:05 -0800
Subject: RE: [e-lang] "Capability Myths Demolished" (was: Software securi ty workshop)

> -----Original Message-----
> From: Tyler Close []
> Sent: Wednesday, December 04, 2002 3:50 PM
> To: ''
> Subject: Re: [e-lang] "Capability Myths Demolished" (was: Software
> securi ty workshop)
> On Wednesday 04 December 2002 18:51, Karp, Alan wrote:
> > Tyler Close wrote:
> > > Given this mechanism, you can implement all the functionality of
> > > the Granovetter diagram.  How can you draw a line between the
> > > Dennis and Van Horn system and E?
> >
> > As described in Dennis and van Horn, a capability contains 
> an identifier
> > for a segment (resource) and a set of rights.  A c-list is 
> a set of handles

I was wrong about this.  The c-list is the set of capabilities associated with a computation, a set of processes sharing a c-list.  The memory addresses w = [i,a], segment + offset, are the handles. 

> > to these capabilities.  The permissions are explicitly listed in the
> > capability and are interpreted on access to the resource.
> I'll have to re-read, but I believe these permissions are for
> memory segments, not for protected procedures. In the case of
> memory segments, you can think of these permissions as equivalent
> to the method names available on a memory segment object.

Certainly, Dennis and Van Horn only describe memory segments, but what they say appears to be applicable to resources (objects) in general.  I also agree that you can think of the permissions as equivalent to the method names, but it is clear to me that they do not.   On page 24 of the longer report they state 

  "A sphere violation occurs if a process refers to a capability that does not 
  exist in the C-list of its computation,  or makes an invalid use of a 
  capability (attempts to write in a segment for which only the execution 
  capability is authorized, for example)."  

The first case is identical to E, a reference that doesn't correspond to a facet.  The second is clearly different (to me at least).  In E, there's no entry in the facet's vtable for the method; in DVH, the vtable is the same for all segments, but a check against the permissions listed in the capability reports a violation.   

> In the case of protected procedure capabilities, the capabilities
> are remarkably similar to E capabilities, right down to the use of
> a vtable-like structure for entry point selection.

The first case, but not the second.  Could DVH have a separate vtable for each capability?  Yes.  Did they?  I don't believe so.  The essential difference to me is the fact an E capability is a reference to a facet that has vtable with a subset of the methods available on a resource.  In DVH a capability is a piece of data that contains a reference to a resource and a list of permissions. 

> > My understanding
> > of an E-capability is that it is an identifier to a facet 
> of a resource,
> > identical to an object handle.  The permissions are 
> implicit in the facet
> > being identified.  No interpetation of rights is needed; 
> either the facet
> > has the method, or it doesn't.  That's why in my paper I list
> > E-capabilities as different from what I call traditional 
> capabilities.
> This is the same for protected procedure capabilities in the
> Dennis & Van Horn system. E-capabilities should not be listed as
> different. They are not different, and listing a difference can
> only create more false impressions.

To me the difference is the explicit listing of permission in the DVH capabilities and implicit nature of the permissions associated with an E facet. 

> Tyler
> PS
> Thank you *very* much for the URL for the Dennis & Van Horn paper.
> I wish all this stuff was easy to get at. Maybe there would be
> less confusion.

Glad to be of help. 

> _______________________________________________
> e-lang mailing list

Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1141
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
e-lang mailing list