On Mon, 2006-03-27 at 07:57, Ludovic Court?s wrote: > Tom Bachmann <[EMAIL PROTECTED]> writes: > > As described in one of my mails [1] to coyotos-dev and somewhere on > > the E language homepage [2] it is possible to implement transparent > > "remote" capabilities, i.e. caps that are invoked like normal local > > ones but that actually invoke servers on other machines over the > > net. > > That is feasible, except that you lose confinement (i.e., the bit > representation of capabilities is visible to the participants, so one > can transfer capabilities off-line, e.g., over the phone), unless you > consider that some ``trusted kernel'' hides that representation to > applications on both ends. This is what is proposed in [0] where the > trusted thing is the language runtime running on both ends.
I don't entirely understand what you mean by "lose confinement". If you transmit a capability to a process which you don't know is confined, then there is a possibility that that capability will get spread around far and wide. But you can still be *aware* that the recipient is possibly unconfined. If you look at the Constructor pattern, consider whether it would claim that a network capability proxy (the thing which can respond to remote invocations) is confined. Also, when you say "the bit representation of capabilities is visible", I agree in terms of being unable to prevent the transmitted capability from being copied around everywhere. But that isn't actually unique to distributed capabilities - you can have the same problem locally! E's CapTP ( http://www.erights.org/elib/distrib/captp/index.html ) provides the property that giving a capability to a hostile remote system does not expose you to any additional vulnerability than it would if you gave the same capability to a hostile local process. -Eric _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
