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

[Matthieu Lemerre]

Marcus Brinkmann <address@hidden> writes:

> 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).

It seems that a pointer to the real object would be sufficient.  The
cost would be one indirection.  But (as I wrote in the other mail),
does the number of indirections increase with the mapping hierarchy,
or is it constant?  I think that if you have 2 pointers:

-One on the root (i.e. the object on which the operation is done)

-One on the "parent" object in the "mapping" tree (i.e., which object
 is this object forwarding)

But I never even used EROS, so how dare I tell :)


[...]

>
>> 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.

OK.  Several comment/issues come to my mind:

-If a server serves a ressource to a client, and the client is
 destroyed.  How is freed the ressource?  If there is no reference
 counter, then the killer (which may be the creator of the client)
 would have to free it explicitely.  But this suppose that it has
 knowledge of what capabilities the client had.  How can he knows
 that?  Isn't it exposing too much information to the parent if he can
 know that?  If the killer does not release the ressource, is the
 ressource lost? 

-We could prevent a server to access the information contained in the
 reference counter, if needed.  I'm not sure this security policy is
 something we need in the Hurd, so maybe it should be an exception,
 and not the general rule.

To conclude, I don't know how a system without reference counting
would look like.  Especially if we want to emulate POSIX.  But maybe
we should look again at how it's done in EROS?


>
>> 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.

I'm not sure we are speaking about the same thing here.  When the
client has to map a capability to a server it does not trust, I think
it would want to REVOCABLY COPY the capability to that server, so that
it can itself revoke the right that this server has to use the object.

For instance, a client may want to give some server acces to a file,
and that server would write something into the file.  Then, it would
have to revoke the mapping, because else the server could use the file
as memory provided by the client.

The allocating server (here the filesystem) does not intervene.


[...]

BTW, I haven't told why I named capabilities which shouldn't be copied
authentification tokens.  They would have been better named "exclusive
capability" or something like that.  This is because we don't want
these capabilities to be copied without the mapper being able to
revoke the mapping (like for the notification server example).

Thanks,
Matthieu