Re: Why COPY != SIMULATED COPY

[Jonathan S. Shapiro]

On Wed, 2005-10-19 at 15:47 -0400, Jonathan S. Shapiro wrote:
> Correct on all points, except that no paranoia is required for REVOCABLE
> COPY to be a big problem.

Excuse me. That was worded very badly. What I should have written was
that the *use* of REVOCABLE COPY can create big problems, because it can
very easily become impossible to reason (formally or informally) about
the behavior of programs that rely on the revocable capabilities.

That is: there is a set of known-safe idioms for use of REVOCABLE COPY,
but we only know of a very limited number of such cases, and using
REVOCABLE COPY as a general capability transfer mechanism is not one of
the safe idioms.

It is an interesting research question to learn what *other* idioms
around REVOCABLE COPY might be safe, but I suggest that Hurd should not
wait to learn the outcome of this research. :-)


In hindsight, the limited set of safe idioms may explain why we did not
run into trouble in EROS when we declared that wrappers could not wrap
wrappers. More precisely, we allow this in the memory tree but not in
the IPC path.

I originally introduced this restriction into the IPC path because
nested wrappers made a mess for IPC atomicity. Look at the code at:

http://www.opencm.org/opencm/~/PUBLIC/EROS/DEV/eros/787/src/sys/kernel/kern_Invoke.c#895

You will notice that this code FAILS to save the old value of
inv.entry.key[2] anywhere. Clobbering something in the inv structure
actually isn't a big deal: the important issue is that we aren't saving
the originally transmitted capability into the wrapper node. THIS IS A
BUG!

The implementation problem with permitting a wrapper loop is that all of
these state changes to the wrapper need to be undone if it is later
determined that we will not be able to execute this invocation -- this
is required for system call atomicity. The cost to record the necessary
information to allow these updates to be undone later is considerable.

And in fact, the provisional Coyotos IPC spec does not implement the
equivalent function by updating the wrapper object, precisely because
that was a problem for atomicity. On the other hand, the provisional
Coyotos IPC spec does not support wrapper nesting.

I would be willing to reconsider this, but I would need to see two or
three compelling use cases first.

shap