Re: Comparing "copy" and "map/unmap"

[Marcus Brinkmann]

Hi,

not a complete answer, but just a few notes.

> > The *good* part about the COPY model is that it makes object creation
> > and capability copy cheap. The *bad* part is that selective revocation
> > requires some application-level planning. In Coyotos, the way you do
> > selective revocation is that you insert a transparent forwarding object
> > (this is a kernel-implemented object) in front of the real capability,
> > and then pass the forwarding capability to the receiver instead of the
> > real capability. Later, you can destroy the forwarding object, which
> > revokes their capability.
> 
> OK.  So you have to create a new forwarding object for each new
> client, but I assume this is a relatively cheap operation.

I think there are good reasons to believe that a forwarding object can
be implented efficiently in the COPY model, while we know for sure
that the reverse is not true (ie, implementing COPY in the REVOCABLE
COPY model is inefficient).

I had some discussion about this with Shap in Dijon, and I think there
was only a tiny issue in the EROS/Coyotos design which had to be taken
care of.  I think it was something about (indirectly) correctly
identifying the sender of the message, or something about branding.  I
distinctively remember the moment we talked about it, but the
technical details escape me.  Maybe Shap can fill in the gaps, or I
will recollect my memories when looking through my notes.

> What we originally planned was to have the cap server be also a
> reference counter, and thus the place where ressource accounting would
> have been done.

Matthieu is right, and we know that some reference counting is needed.
However, it would be wrong to make reference counting mandatory.
There are several reasons for that:

1. Reference counting can be a violation of security policy.
   Sometimes the server must be ignorant about the number of users
   left.

2. In general resources should be reclaimed explicitely, not
   implicitely.  Implicit deallocation can be emulated where desired.

3. We simply do not need reference counting everywhere.  For example,
   task creation and destruction already is explicit in our design,
   not implicit.

We have not even begun to look for a better Hurd server architecture
which does not rely on reference counting everywhere.  This is
something still on my TODO list, and I have some ideas about it.
Imagine we would opt for a persistent design, where users are
identified by their session.  Than that session can do explicit
allocation and deallocation and reference counting for the user, and
no system-wide reference counting should be needed.

This suggests to me that we should try to use less reference counting,
and not make it a fundamental paradigm of our operating system.

> You scheme is approximatively what I have written in
> http://lists.gnu.org/archive/html/l4-hurd/2005-09/msg00056.html (based
> on Marcus' work).

I should note that this work represents everything I knew before Dijon :)

By todays standard, I tend to think that this work represents a
negative result even more than a positive one (yes, you can emulate
COPY in L4sec, BUT look at what it costs).

> For 3., in the Hurd most often the client does not fully trust its
> server.  So it wouldn't want to give to it ressources that he couldn't
> revoke later.  So I think the operation we would want here is more
> REVOCABLE COPY.

This is wrong.  The server implements the object, and never
distinguishes different users of the same object.  So, if the server
wants to reclaim the object, it will just destroy it completely,
revoking _all_ copies of the capability.  This is not selective
revocation.

> * The cap server was planned to have three roles: a trusted third
>   party used to reestapblish capability copy semantics, a point for
>   accounting ressources, and a reference counter.  If we have copy
>   semantics, how can we have the two other functionnalities.

I am not so sure about the resource accounting part.  In fact, I think
resource accounting is one of the big problems that our design work so
far leaves completely behind.  We pretty much ignored it, but in fact
I think it is deeply related to our other problems we have struggeled
with (reference counting, server design, etc).

Thanks,
Marcus