Exercises for Capability Platforms

I operate a computer which hosts an E-vat, and I write code for that vat. There is another computer somewhere with an E-vat called V. I trust the operator of V and some code H, but not other code Y that both run in vat V. The nature of H at V will emerge below. I want to send my proprietary X code to V in order to interact with Y natively—with no membranes. The operator of V is willing but does not want to become involved. He has provided H so as not to become involved. H is a perfectly normal E program playing by current E rules.

As an initial condition presume that I have, within my vat, a remote reference to H and that H behaves as described below. I send to H an AST (abstract syntax tree) of my proprietary program. H performs an Eval on the AST and gets a value X' that is a function whose parameters encompass all of the free variables of the function body—i.e. there are no free variables in X'. (I view stdout as a free variable.) Along with the AST, I send several other remote references, including to one to Y. Somehow the references to Y become local, since they are indeed local to V and H invokes X' with the local references. There may be other standard local facilities in V that I trust and H also includes references to those as it invokes X'.

It seems to me that my code can invoke Y without communications delay, or even membrane overhead. My code cannot violate the abstractions of Y nor conversely. As it stands this does not achieve confinement although it may be part of a confinement pattern.

There remain in this pattern problems of resource management—space and time.

During the discussion the question arose of whether the AST was pure data. Here I assume that it is. The Scheme that I run yields 6 for “((eval (lambda (x) (+ x 1))) 5)”. I consider this a bug; I think it should reject this construct. “((eval (quote (lambda (x) (+ x 1)))) 5)” is fine and it also yields 6. Perhaps it would be possible to extend the AST to allow remote references within but I would have to see the specs.

Mark Miller comments on this as follows, and he is entirely correct:

As to whether this is support for “mutual suspicion”, we need the usual separation of integrity/safety vs availability/liveness vs confidentiality. Within a single E vat as you describe, there is perfect (as far as we can tell) support for integrity/safety among mutually suspicious bits of code, such as X and Y, and almost perfect lack of support for availability/liveness. In other words, under your assumptions, you know Y can’t cause X to do bad things or steal from X the ability to do bad things that X wouldn’t do. But Y can prevent X from doing anything. Bad things won’t happen. But good things may or may not happen.