[e-lang] Surprising consequences of pipelining?

[Kevin Reid]

Consider this code:

   def coerced := (def guard := thing <- __getAllegedType()) <- 
coerce(thing)

If I understand pipelining correctly, since the 'coerce' message is 
sent to a promise whose tail is in 'thing''s vat, that vat has the 
opportunity to respond arbitrarily to it - and then resolve 'guard' to 
a completely unrelated object!

It seems quite natural to assume that, given the above code, if 'guard' 
resolves to an already-known guard, then 'coerced' has passed that 
guard's coercion; but this does not hold given pipelining.

Is there some reason this cannot happen, or an obvious reason for an E 
programmer to not expect the above code to function as intended? Have I 
forgotten somewhere that this is documented?


The rest of this message assumes that this problem does exist as I have 
described it.


A ahort description: An unresolved promise will behave as intended by 
the holder of its resolver, *but not necessarily as intended by its 
future resolution*.


Things that could be done:

   1. Throw out pipelining.

   2. Make any given inter-vat promise never resolve to being the same 
as another reference. This prevents programs from being able to have 
expectations of past behavior based on sameness tests of the 
resolution; they must always assume that there might be a transparent 
forwarder. This would also make it impossible to pass PassByCopy 
objects except as message arguments; they would otherwise have to be 
passed as if PassByProxy.

   3a. Make available in the safeScope an operation for responding to 
the eventual sends to a promise before that promise is resolved. This 
restores the property that "a malicious vat hosting one set of objects 
can only cause external effects equivalent to a correct vat hosting 
some different (maliciously coded) set of objects" (from 
<http://www.erights.org/elib/capability/ode/ode-protocol.html>).

   3b. Add support for unprivileged comm systems.

   3. 3a and 3b are different descriptions of approximately the same 
change. Ideally, having 3b, specifically documented as being a means 
for 3a, would remind the programmer that they cannot rely on 
pre-resolution behavior to correspond to post-resolution identity.


-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>