Compiling E: Phases of Transformations

[Mark S. Miller]

At 10:50 AM 8/7/00 , Ken Kahn wrote:
>From: "Mark S. Miller" <markm@caplet.com>
> >
> > Language:        Kernel-E -- portable interface from virtual machine
> >                         The subset of Auditable-E that passes audit.  Seen
> >                         by debuggers and other meta-level tools.
>
>Everything you wrote made sense to me until I saw "debuggers" here. Wouldn't
>someone want to debug at the level of User-E and not Kernel-E? Doesn't the
>ability to debug make this whole transformation scheme much more
>complicated?

Answering your second question first:

The ability to debug certainly makes this whole thing more complicated, but 
what other choice is there?  A language must have debugging support to be 
usable.  Without it, you only have a sterile academic exercise.  OTOH, the 
virtual machine doesn't necessarily need to provide this support.  As Udi 
(Ehud Shapiro) taught us regarding FCP, and as you remember, but for 
everyone else's benefit:

<background>
First, imagine a meta-interpreter (an interpreter written in the same 
language it interprets) that *absorbs* inter-object causal signals -- in E 
terms, it maps an interpreted inter-object send, call, return, throw, or 
escape into the identical base-level construct, as in the old Kernel-E 
meta-interpreter sketch at http://www.erights.org/elang/elangmanual.pdf .  
(In FCP terms, it maps interpreted variable binding into the identical 
base-level variable bindings.)  Not only can a program be run on the 
meta-interpreter rather than directly on the virtual machine without 
changing its meaning (as is the case for any meta-interpreter), but 
additionally, since inter-object signals are absorbed (mapped only to 
themselves -- the identity encoding), a program *with live connections to 
other other base-level objects* can be run at base level or interpreted 
without changing its meaning.

Now imagine that we enhance such a meta-interpreter to report back to its 
spawner debugging information about the program it's interpreting.  Clearly 
the virtual machine hasn't changed, and clearly capability security hasn't 
been violated.  From the base-level point of view, the program being run is 
the interpreter, not the interpreted program.  One should consider the 
interpreted program to be "real" only to the extent that the interpreter is 
trusted.  In the case of a debugging interpreter that gives its spawner 
meta-level access and control of the interpreted program, such trust would 
necessarily involve trust in the spawner (and therefore, in whoever the 
spawner delegates such access to).  Not surprisingly, this situation is 
exactly the same kind of subjective aggregation by which we reason 
about trusting vats vs objects in vats 
http://www.erights.org/elib/capability/ode/ode-protocol.html#subj-aggregate .

Finally, if we are in a position to run a program under an interpreter of 
our choosing, we are in a position to, instead, transform the program into 
one that's equivalent to running the original program under our chosen 
interpreter.  If the interpreter is a vanilla interpreter that changes 
nothing, the transformed program can simply be the original program.  OTOH, 
if the interpreter is, for example, one that provides debugging access and 
control, then the transformation should produce a program that, when run, 
volunteers to its spawner access and control to the subset of its semantics 
represented by the pre-transformed program.  Whew!
</background>

It is possible that we should take this route.  If we do, the virtual 
machine can be simpler, as it wouldn't have to provide debugging hooks.  
This approach is also inherently portable.  However, I don't know if it can 
really be efficient.  In any case, this approach gives a principled 
perspective to deal with the security implications of debugging.  Even if we 
go the conventional route and give the virtual machine a standardized 
portable debugging API, we should probably make it security-equivalent to 
the debugging API that would result from the meta-interpretive approach.

The other reconciliation of debugging and capability security is KeyKOS 
(and, I assume, EROS).  We need to further reconcile the KeyKOS and the 
meta-interpretive approaches to secure debugging.  More on this later.

What do Scheme and ML folks do about portable debugging these days?  What 
about W7?  Does it reconcile debugging with capability security?


         Cheers,
         --MarkM