[e-lang] security policies for debugging (was: Object reflection)

[Mark S. Miller]

At 08:31 AM 1/12/2004  Monday, Mark S. Miller wrote:
>At 12:40 AM 1/12/2004  Monday, Fred Spiessens wrote:
>>Anybody from the E-language community that could tell us how the E-debugger 
>>will work in this respect?
>
>Use refraction rather than reflection. See
>http://www.eros-os.org/pipermail/e-lang/2003-February/008464.html
>and
>http://www.eros-os.org/pipermail/e-lang/2003-February/008465.html
>
>Although the above story of refraction support in an E-like language is 
>still speculative, [...]

My previous message explains E's long term desires. In the short term, I 
expect we'll implement the following special case of general refraction 
(adapted, if I recall, from similar plans we had for Joule):

Consider a vat to be as-if a separately instantiated interpreter for 
interpreting the portion of the distributed E reference graph which it hosts:
* each object in that vat (both state (instance variables) and 
  code (Kernel-E AST)), 
* the references among them, both live and sturdy,
* the pending activities for these objects to get around to (both stack 
  frames and queued message deliveries 
  http://www.erights.org/elib/concurrency/queuing.html ), 
* the incoming and outgoing parts of vat-crossing references, 
* and the outgoing messages not yet known to be enqueued by the receiving vat.

Ignoring partition, checkpoints, rollbacks, and the possibility of multiple 
co-existing comm or persistence systems, does that account for all of E's 
per-vat abstract computational state? I think so. (A lower level mechanism
without all these caveats would consider each vat to be an island, and the 
comm and persistence systems to just be more E code. We should build support 
for the high level view on mechanisms supporting the low level view.)

The creator of a vat already gets a capability that gives it special powers 
over that vat, such at the ability to shut it down 
http://www.erights.org/javadoc/org/erights/e/elib/vat/Vat.html#orderlyShutdown(java.lang.Throwable)
. If a vat were enhanced to be as-if a debugging interpreter, then the 
creator of a vat would have debugging authority over that portion of E 
computation hosted on their vat. The Brand-like rights-amplifying operation 
might be something like:

    def optAliceRepr := vatA.getOptInternals(alice)

If alice is a normal use-reference to an object hosted by vatA, then 
getOptInternals/1 would return a Repr object giving the ability to inspect 
and perhaps control Alice's internal representation. (This is like 
amplifying a KeyKOS start key into a domain key.) Otherwise, let's say 
getOptInternals/1 would return null.

Like the KeyKOS Brand mechanism, this supports only one level of nesting. 
With only this mechanism, the vat (like the KeyKOS Domain) would be the only 
supported granularity of refraction. However, this mechanism doesn't 
directly support confinement of vats.

Note that all claims of object confinement are necessarily relative to a 
their hosting vat (or, more generally, their hosting interpreters / TCBs / 
kernels). These claims are only good to the extent that their hosts don't 
abuse their authority to violate the confinement of the objects they host. 
In E, there's a separate DeepFrozen guard/auditor for each host. Each 
represents the claim *by its host* that various objects are confined. These 
are distinct, because different hosts are separately trusted.

In an E-like context (and, I believe, in a Mozart-like context) these 
limitations are usually appropriate -- they reflect the inescapable 
constraints on trust resulting from distributed operation on mutually 
suspicious hosts. By contrast, KeyKOS (and EROS) have the luxury of assuming 
a mutually trusted TCB. See 
http://www.erights.org/elib/capability/dist-confine.html .


Finally, notice that all this corresponds well to debugging distributed Java 
computation, where a JVM process corresponds to a vat. The JVM's debugging 
API provides debug-level authority exactly at the granularity of the 
individual JVM. To separate rights to debug, you need to separate your 
computation among JVMs appropriately. This corresponds most closely to the 
"lower level mechanism" referred to above. In both cases, such a low level 
mechanism cannot itself provide the amplification of use-references into 
representation-references, as it cannot recognize the existence of 
remote references. This amplification needs the cooperation of the 
respective comm systems which create the notions of remote references.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM

-
Please send submissions to users at mozart-oz.org
and administriva mail to users-request at mozart-oz.org.
The Mozart Oz web site is at http://www.mozart-oz.org/.
Please send bug reports to bugs at mozart-oz.org.