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

[Matthieu Lemerre]

"Jonathan S. Shapiro" <address@hidden> writes:

> Note that the kernel is in a position to cache the traversal after you
> execute it once.

That's actually what I meant with my 2 pointers: one would have been a
pointer to the end of the traversal.

>
>> > 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:
>
> Some of this may be easier to see after you read my note on storage
> allocation. My comments below assume that you have done so.
>
>> 
>> -If a server serves a ressource to a client, and the client is
>>  destroyed.  How is freed the ressource?...
>
> If the server paid for the storage in the first place, you already have
> a bigger problem. If it did not, then why do you care? Let the client
> clean up its own messes!
>

OK.  This works because you manage that every single byte of ressource
is allocated by the client.  Thus, upon client destruction, every
object is automatically destroyed without the server knowing it.

We originally planned that metadata used to manage the ressources was
allocated by the server (because, I think, we do not know how to
achieve this on L4, where the smallest allocation unit is the page).

BTW, I'm interrested by your space bank solution in the other mail.
How do you manage that the server does not write beyond the space bank
for instance?  Does each server has one page where their allocated
space banks are allocated, but on behalf of the client by the kernel?

>
>> 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?
>
> For POSIX, you definitely need reference counts, but these are not
> capability-layer reference counts. These are reference counts that are
> implemented by the POSIX server, which is an entirely different thing.
> There is absolutely no need for these to be implemented in the kernel.

In the Hurd, we don't have something like a POSIX server.  I hope that
it would still work if this POSIX server was split into several
servers, but I would have to study how you do reference counting on
your POSIX server first.

>
>> > 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.
>
> When a client transfers a capability to *anyone* it may want to revoke
> that capability. It has nothing to do with whether the receiver is a
> server.

Right, but it seemed to me that it was the most common use case.

>
> But we need to challenge your assumption here: once I give a
>capability to a hostile party, I have to assume that the hostile
>party misuses it.  If they *do* misuse it, then either:
>
>   1) The object is robust against misuse, or
>   2) The object itself is now corrupted.
>
> In the first case, there is no need to revoke the capability. In the
> second case, revoking the capability will not help. What I need to do at
> that point is revoke the *object*, because it is now garbage.
>
> The case for revoking the capability here is the possibility that the
> receiver is *now* trustworthy, but may in the future become compromised.
> It is simpler in this case to design the receiver not to hold on to
> capabilities that it should not retain. Also, this does not address the
> question of how you will know in the future that the receiver is no
> longer trustworthy.
>
> In EROS, the common pattern of exclusively used and confined servers
> tends to make this a non-issue in our system designs.
>

I think that my example (again :)) with the notification server does
not fall into these two categories.  A client would allocate some
space on the notification server, to receive messages.

In proper use, it would give the capability to a server so that this
server could send message to it.

The problem is that if two servers are concurently using the same
capability, then one message would be erased.  So the object is robust
against misuse, but not for concurrent misuse.

So when the client is done with a server, it could revoke the
capability it gave to it to give it to another server.  By doing so,
it ensures that there is always only one sender of a message to a
message box.

This is an example, maybe we don't need a message server in EROS (we
planned to use this for blocking RPCs).  But still, a similar example
could occur (revocation to ensure exclusivity).

>
>> 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.
>
> Yes. But how does it know when to perform this revocation? If the other
> party (what you call the server) performs a close()-like operation, or
> otherwise signals that it is "done", then you have a natural place to
> revoke that capability. If they do not, and some watchdog goes off, then
> what you know is that the file is probably corrupt and the right thing
> to do is to destroy the file.
>
> This is an integrity issue, not a security issue. Security issues are
> relatively easy. Integrity issues are really really hard. Coyotos has
> all of the mechanism needed, but *nobody* knows a consistent set of
> design patterns for when to use them.
>
> But yes, this is a good example of a place where you would impose a
> wrapper for the purpose of imposing a temporal scope on the
> relationship.

OK. I saw this as a security issue because a malicious server could
try to erase the message data, but you're right, this server does not
even need to be malicious.

>
>> 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).
>
> I am still not sure why you want this. You appear to be concerned about
> capability leakage. If you do not trust the downstream party, then
> either
>
>   1) You shouldn't send the capability. Even if it cannot leak
>      directly, the hostile receiver can act as a proxy.
>
>   2) You should confine the receiver so that it *cannot* leak.
>
> Regardless, if you pass a wrapped capability and later destroy the
> wrapper, you are guaranteed that no further use of the wrapped
> capability through that wrapper is possible.

My only point was to show examples were revocable capability was
useful, but everybody already knows this since you have them in EROS
:)

Thanks,

Matthieu