Re: capability types

[Jonathan S. Shapiro]

On Mon, 2005-10-17 at 11:55 +0100, Neal H. Walfield wrote:
> At Sat, 15 Oct 2005 16:42:51 -0400,
> Jonathan S. Shapiro wrote:
> > I think we are confusing interfaces for types. dir_lookup("name"), for
> > example, can return an arbitrary capability type. Once you have the
> > capability back, however, that capability has well defined behavior, and
> > you can ask the capability what its behavior is.
> 
> This indeed seems to have been the case.  Thanks for taking the time
> to clarify the terminology.
> 
> To summarize my understanding from this thread:
> 
>  - a capability *names* an object
>  - an object *implements* a set of methods
>  - the set of methods an object implements is *the interface* it
>    implements
>  - an IDL can be used to define an interface *type*
>  - interface types are purely advisory and strict interface type
>    checking cannot be performed based exclusively on this information

Almost. The capability also names the interface. The rest is correct.


But now let me shake it up a little more.

There is a difference of convention between OS people and programming
language (PL) people about what the term "object" means. In the OS
world, when we use the term "object", we generally mean a concrete
resource of some kind. That is, we are speaking about representation
state without regard to behavior. In the PL world, when people refer to
an "object", the notion they mean is "some uniquely identifiable thing
having some specific behavior."

I (and several of my students) work with people in both camps in
connection with these ideas. Among ourselves, we often use the terms
exactly as you have done. When fine precision is required, we prefer the
following definition:

  A capability is a pair whose first element denotes some (opaque)
  representation state and whose second element denotes an interface
  that may or may not operate over that representation state.

If you are familiar with the way higher-order languages are implemented,
you will know that first-class procedures have (possibly empty)
closures. Another perfectly good way to view a capability is that the
interface is a vector of procedures all of which are closed over the
same closure, and the "representation state" is the closure. At the
representation level this looks a lot like a CLOS object.

We particularly like this framing when we are doing formal stuff,
because this justifies the statement that

  The semantics of capabilities is precisely the semantics of
  the lambda calculus with side effects.

This implies that if our user-mode services (objects) are written in
analyzable languages, we can extend the semantic contract successfully
across the OS/language barrier, which has traditionally been an opaque
boundary. This opaqueness has been the source of an unbelievable amount
of confusion and bad modeling in the worlds of access control and
security policies. It offers a fundamental extension of power in
object-based operating systems.

shap