[cap-talk] capability copy and capability map

[Marcus Brinkmann]

At Wed, 25 Oct 2006 14:30:53 -0700,
"Mark Miller" <erights at gmail.com> wrote:
> 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.

First, let me stress that by "wrapper" I mean an object that allows to
selectively revoke all copies from the capability derived from the
wrapper, and nothing more.  In particular, this does not mean
interposition of an IPC monitor.

This would mean that as long as the wrapped copy is not revoked, the
wrapped capability and the wrapper capability are semantically
indistuingishable.  The only difference is object life time.

I am not sure that these are the semantics of EROS wrappers, but I
want to be clear here.

My motivation is to ensure that holding a copy of the wrapper
capability designates, at that point in time, exactly the same
authority as the wrapped capability.  Again, the difference is not
which operational authority I hold, but for how long I can hold it.

With this assumption, I do not see how a wrapped object can export any
further services.  I can see how the server implementing the wrapped
object can provide further services on different objects which may
allow to get more information about wrapper capabilities, including
comparison services against wrapped capabilities.  I think that the
usefulness of such services is quite narrow though, because this means
that the implementation of the service needs to be fully trusted.  I
would also be concerned about performance.  For both reasons I think
that this strategy is certainly unfeasible if every capability
delegation is revocable.

In my reply to Charlie I give an example based on the L4 kernel design
where I motivate the distinction I am making above between authority
and life-time.  Even if you want to reserve the concepts of identical
authority and rights for co-equal capability copies, I think the
distinction can be generally useful in analysis (I am open to
suggestions on terminology).

Now a more general comment: I understand, and tentatively agree with,
your position in the context of capability systems which have
capability copy as the main paradigm for delegation.  However, as you
pointed out, in a system where revocable delegation is the main (or
only) paradigm for delegation, eq? ceases to be useful, because the
answer can be expected to be "false" most of the time[1].  Under this
assumption, challenging the specific semantics of eq? that you propose
based on abstract considerations seems a reasonable approach.  The
question to me is if this is a limiting assumption or not in actual
operating system design practice.  I think the answer to that question
is non-trivial and still open.

It may be that such a system would turn out to be different enough
from traditional capability-based systems to justify a separate, or
expanded, terminology.

Another point, even more vague and general: It strikes me as odd that
in the EROS system design storage resources are managed vertically via
the space bank hierarchy, but authority resources are managed
horizontally.  I think it is worth pointing out that the L4 proposal
basically is to have a common management model for all kinds of
resources.  This seems to me to be a respectable goal, which, if
successful, includes a challenge for the traditional capability copy
camp as well: To justify making a distinction.

Thanks,
Marcus

[1] It is possible to devise a system even in this case that gives
"true" as an answer in the cases where it is important, like the
"grant matcher" scenario.  In practice it turns out to be infeasible
to make this happen in the context of a multi-server based microkernel
operating system due to performance considerations.