[cap-talk] Another "core" principle - Brinkmann, memory

[Jonathan S. Shapiro]

On Sat, 2006-12-30 at 00:01 -0800, Jed Donnelley wrote:
> At 12:27 AM 12/29/2006, Jonathan S. Shapiro wrote:
> >The "traverse" right is conceptually equivalent to having a service S
> >that implements two facets A and B, will directly disclose some
> >capability to A, but will only wield it indirectly for B. The only
> >difference is that by reifying this right in the operational semantics
> >it becomes possible to do information flow analysis without analyzing
> >the code of S. We haven't exited the capability model at all here. It is
> >merely an optimization.
> 
> I'm afraid you lost me in the above.  As I understand what you wrote
> above, any subject (process/active object) with the capability "B"
> (I'm not quite clear if B is a capability or not) can communicate
> it.  That fits my understanding of the base object-capability
> paradigm.  When you say "conceptually equivalent", to me they
> seem to differ in that in one instance a subject has a capability
> that can be communicated and in the other a subject has a capability
> that can't be communicated (violating the base object-capability
> paradigm - in my book anyway).

You misread the example. The server S is holding, internally, a
capability C. Invokers of facet S.A can obtain the capability C (because
S will disclose it to wielders of that facet). Invokers of facet S.B
cannot (because S interposes a restrictive proxying function). This is
substantially what the weak capability does. In substance, the weak
capability is an efficient implementation of a particularly useful
membrane.

> >However, this optimization is important because it supports two other
> >things that we want: (1) it makes it possible for all mapping-related
> >metadata (i.e. page tables a.k.a. nodes) to be explicitly allocated,
> >which is necessary for proper storage accountability (2) it makes
> >possible the implementation of a particular form of encapsulation that
> >is essential to user-level pagers: the pager must provide a space to the
> >client, but for practical implementation it must be able to know that
> >the client cannot corrupt (i.e. alter) the metadata managed by the
> >pager.
> 
> I guess that puts the discussion beyond that appropriate for cap-talk.

Yes and no. I agree that discussion of paging is OS-specific, but think
that the topic of storage accountability is general, and greatly
under-attended.

The user level pager issue is a particular instance of a general
problem: an object graph maintained by one actor that is explorable by a
second actor, wherein the modifications possible to the second actor are
restricted. This is a surprisingly general pattern.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100