[e-lang] Re: 3-vat introduction

[Allen Short]

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
Type: application/pgp-signature
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