[e-lang] TextWriter/__printOn expectations/contract questions

[Kevin Reid]

On Mar 4, 2005, at 19:25, Mark Miller wrote:

>  There is a danger here. But so long as the extra information is 
> limited to data and DeepPassByCopy objects, it would seem we already 
> have this danger with the TextWriter indent level. We should examine 
> how one might abuse such a channel.
>
> These issues remind be of the Throwable issue: Prior to the 
> DarpaBrowser review, I thought that the restriction that one could 
> only throw DeepPassByCopy data was adequate protection. Perhaps 
> there's the same rude surprise lurking here?

It seems unlikely. This is (relatively) explicit data flow, whereas the 
problem with exceptions is/was (assuming the DeepPassByCopy 
restriction) that they provide a path for data flow which is implicit 
in the code, and therefore 'outside' of the capability rules we expect.


My current attempt at a solution (which I have implemented in E-on-CL)
   <http://www.eros-os.org/pipermail/e-lang/2005-January/010416.html>
does not completely prevent this, as in order to allow *unresolved* 
references to sealed-boxes to be thrown, there is an operation which 
allows 'throwing' arbitrary values which any try-catch can catch 
unaltered.

Among the consequences of this is that in order to maintain confinement 
of a subgraph, all calls into it must catch every exception, or it 
would be able to leak its state and authority.

This is definitely a poor situation (though I think it's slightly 
better than the current one where information may *accidentally* be 
leaked).

I have one idea so far for a solution, which, as usual, I just thought 
up while writing this message:

The pseudo-ejector which is provided to the 'server', instead of acting 
as a sealer as I described before, acts as a resolver (i.e. stores a 
value and becomes disabled), and the throw() does not pass any value 
which is expected to reach the client.

Then, the client, if it receives a broken reference, checks the promise 
which the pseudo-ejector resolves, and if it is resolved, then it 
contains the problem.

This would simplify the semantics of throw()ing that I originally 
proposed, as there are no 'special cases' for sealed boxes.

It has the disadvantage that there is no association between the broken 
reference (created by the 'server''s vat at end-of-turn) and the 
client's check of the promise, so the client might determine that its 
pseudo-ejector was used, while on the server side the exception was 
caught, discarded, and a different exception was thrown. This is not 
necessarily bad, but it is a rather strange behavior if one is used to 
exceptions in languages like Java, or even Common Lisp.

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