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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
