[cap-talk] capability copy and capability map

[Mark Miller]

On 10/25/06, Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> Well, first you would need to convince the L4 group to include the
> discrim or eq? ability.  I think that their rejection of that ability
> is crumbling, but so far it is not part of their published designs.
> In private discussions with various members of the L4 group in
> Dresden, eq? was acknowledged to be a useful operation to have.
> (However, in past discussions there has been considerable difference
> in specific implementations with regards to which capabilities can be
> compared and how efficient such comparisons are).

This question is indeed tricky. As recounted at
<http://www.erights.org/elib/equality/grant-matcher/history.html>, I
have spent years on each side of this argument without a sense of
having arrived at a definitive answer, or really even of having fully
understood the question. Also, as you raise below, even if one accepts
the need for some kind of primitive equality primitive, there is still
plenty of room for arguing about what its precise semantics should be.
As of the time I wrote those pages, perhaps 8 years ago now, I have
arrived at some tentative answers to the questions that I consider
adequate and have used successfully since then. I recount here some of
these tentative answers.


In a pure objcap system without EQ or rights amplification, when Bob
gets from Alice a reference to Carol, Bob's ability to validly trust
that Carol has particular properties is bounded by Bob's trust in
Alice. (If Alice is Bob's client passing Carol as an argument, then
Bob's trust in Carol is bounded by Bob's trust of his clients.) In
this way, the dynamic acquisition of new caps at runtime results only
in monotonic non-decreasing trust along the chains of acquisition
starting from one's initial endowment. To Bob, Carol is only
*according to Alice*.

In the grant matcher scenario, when Bob detects that he gets the same
Carol from both Alice and Dana, then Bob can validly trust that this
Carol has the union of the properties that he attributes to Carol as a
result of the Alice introduction and from the Dana introduction. Where
these properties are in common but the issue is the sense in which Bob
trusts that Carol has these properties, this trust is now bounded by
the union of Bob's trust in Alice and in Dana. By Bob's use of
equality, the two introduction *corroborate* these properties.


> Should the eq? operation yield true when comparing a wrapper and the
> wrapped object?


I would like to start by rephrasing your question. Please let's
reserve "eq" for an equality question which will only yield true when
the two arguments are semantically indistinguishable. If u is the
underlying object and w1 and w2 are two wrappers of it, then

   eq(u,w1) == false
   eq(w1,w2) == false
   eq(w1,w1) == true
   eq(u,u) == true

One can also imagine coarser-grain equality primitives such as the one
you propose, which answers in terms of larger equivalence classes. We
then need to figure out which we need, which we shouldn't have, and
which can easily be expressed in terms of the others. If we need
several, it's more plausible that the finer grain primitives can be
used to express the coarser grain ones than vice versa.

My sense, offered for now without further justification:
We should have eq. We should not have a built in primitive that
ignores wrapper distinctions. But a wrapped object can export a
service that, if it wishes, will vouch for its own wrappers as
belonging to it.


> If wrapping is understood to be used for revocable delegation, I think
> that "yes" would be a reasonable answer to that question.  However,
> one can also make a reasonable argument against is.  But then the
> delegation is not transparent anymore.


If the delegations as separately revocable, then they represent distinct rights.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM