[cap-talk] Selling capabilities programming

[Jonathan S. Shapiro]

On Mon, 2007-07-16 at 20:16 +1000, James A. Donald wrote:
> David Hopwood wrote:
>  > In the language case, the major impact on an
>  > implementation of using password/sparse caps as
>  > opposed to protected/partitioned caps, is that the
>  > former precludes precise GC. This is because there's
>  > no way for the system to trace all of the capabilities
>  > possessed by a domain or to determine whether a given
>  > bit pattern is a capability -- which is the same
>  > reason why password caps have weaker security
>  > properties.
> 
> Tracing all the capabilities possessed by a domain is
> significant overhead and complication - and if a domain
> consists of a user and a substantial set of networked
> computers that are the private property of a particular
> user, may well also be a violation of privacy and a
> security threat against the user...

James:

I think that you and David may be talking at cross purposes. Also, I
think that I am beginning to understand where you and I have
disconnected. David: If I bungle this, please correct me.

There are two schools of thought about how to build distributed
capability systems. For our purposes, I would define "distributed" as
(1) a system involving a large number of machines communicating over a
network, wherein (2) there are a large number of failure domains, and in
particular the design may not assume in general that two nodes are in a
common failure domain.

One view of how to do this (which is the one I prefer) says that you
should build such a system by first building a "local" capability system
consisting of a single capability-based node, and then build a
"distributed" system that composes these local nodes. The other view
says that you should just have one uniform system.

There are several reasons that I prefer the local/global style of
design:

  1. Experience in many other distributed systems suggests that
     loose coupling scales better. How this relates is a long
     discussion. At present I just want to get the issue on the
     table.

  2. Even in a distributed system, the overwhelming majority of
     interactions are local, and considerations of distributed
     failure management are something that can and should be
     separated from the local case.

  3. Because a remote node in a distributed system can disappear
     forever without notice, recoverability tends to demand a
     session-based model (so that session timeouts can be used
     to guide recovery). Purely local capability systems do not
     use a session-based interaction. [Which may be a problem,
     as I started recently to talk about elsewhere.]

David's response suggests to me that he is thinking about language-based
issues (therefore a local cap system) in which GC is used to decide when
an object may be reclaimed. In a language-based system, capabilities are
the only object references, so being able to GC them is important.

What I think this misses is that it would be flatly silly for a
language-based system to use cryptgraphic or sparse capabilities. What
makes more sense is to use object references for the local case and
cryptographic caps for the remote case, and provide a means to
interconvert.

However -- and this is something that E gets wonderfully right -- remote
caps do not have the same semantics as local caps. This is because (a)
the remote node is not in the same failure domain, (b) the durability of
the remote object cannot be determined solely by GC -- an application
level contract is required, and (c) the remote node may persist
independently of the local node.


-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC