[e-lang] Re: 3-vat introduction
washort at divmod.com
Tue Apr 19 12:26:47 EDT 2005
On Tue, 2005-04-19 at 11:42 -0400, Mark Miller wrote:
> Here's your text edited to match what E does:
> > VatA sends a "make Carol available to VatB as" message with a nonce to VatC,
> > then sends that nonce and Carol's SwissHash [a hash of the SwissNumber] to
> > VatB. VatB uses the nonce when retrieving the reference to Carol. If the nonce
> > is not registered yet, VatB's request is queued. Since the nonce isn't
> > registered until after previous VatA->VatC messages are received, VatC can
> > ensure that messages sent by VatB on this new reference aren't delivered to
> > Carol until then.
> Now I'm not sure if this last sentence is what you meant to say, but it's what
> E does, and perhaps it makes the issue clear. If the new reference obtained by
> VatB were a resolved reference, and if it was passed as an argument in a
> message from VatB to VatC, then it would arrive in VatC as a near reference to
> Carol, in which case something else in VatC could do an immediate call on it,
> affecting Carol before "prior" messages sent by VatA were processed.
Ah. Pardon my lack of clarity: the scheme we are considering requires a
VatB->VatC->VatB round trip to establish the resolved reference: VatB
sends the nonce and SwissHash, VatC waits for the nonce to be
registered, then sends VatB the actual reference. The method on B that
receives the reference is not invoked until this round trip completes.
Since VatB does not have a live reference to C until after the A->C
messages complete, I believe this avoids the scenario you describe.
> If we substitute:
> > VatC can ensure that VatB can't send any messages to VatC until then.
> then we'd have the documented DOS vulnerability: VatA can deny VatC's services
> to VatB.
Right. But by not sending VatB a reference to C before all A->C
communication has drained, I think this is avoided -- no messages from
VatB can violate ordering.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20050419/767d5689/attachment.bin
More information about the e-lang