[E-Lang] Re: E questions

[Mark S. Miller]

[The reply I sent following Stiegler's reply. --MarkM]

At 04:48 PM Thursday 7/5/01, Marc Stiegler wrote:
>I have put markm in a closet and am not allowing him out of the closet
>until he has made progress on CapTP, which is critical to progress on our
>contract. So I will do my poor best to answer your questions.

MarcS, your answers have reduced the amount I still need to say to something 
small enough that I'm stepping out of that closet for a moment!  Thanks.


>>[..]I won't go into the
>>reasons why this project needs a new language - I'm not sure I believe
>>them myself [...]

In addition to MarcS' response, I'll add that you should urge them to open 
source their language.  It's hard to think of a non-open successful language 
besides Java.  And during the crucial early adoption phase Sun was 
vigorously claiming that Java would be open.

Once they decide to open their, then they'll be more likely to pre-emptively 
question their decisions as they might anticipate others will question them.


>[...] E explicitly acknowledges that "if the code is on your
>machine, you own it", which is the real life truth anyway, so mucking
>through your own entire vat is not considered a security breach :-) 

While that's true, something finer grain would have been preferred if it 
could be made to work.  As in all such matters, my original model for how I 
wanted this to operate (and my model for how I want inter-vat debugging to 
operate) is based on how KeyKOS does it.  In some fundamental sense, I 
believe, Norm and those guys came up with the right thing for reconciling 
security (including confinement) with debugging and maintenance of the 
viability of a system of persistent computation.  I recommend taking a good 
look at it.

I ended up in the current (unpleasant but tenable) position by realizing 
that, in order to preserve E's concurrency control guarantees (the executing 
turn/even has mutually exclusive access to everything it has synchronous 
access to -- all of which are therefore in this vat), a conventional 
control-flow debugger would have to seize control of the vat as a whole.  
Why?  Because while the current computation is suspended, eg, at a 
breakpoint, nothing else may proceed in that vat.  Therefore the debugger, 
and the person operating the debugger, are all parts of that vat's TCB.


>Markm
>has some thoughts about how a secure distributed system debugger would work
>without access to all the vats for all the parties, which would of course be
>a whopping big breach; markm will have to tell you his thoughts when he is
>again allowed to see daylight :-). 

Unfortunately, even though I'm peeking out of the closet here, this is 
indeed too big a topic to cover well here.  The short form is that debugging 
access to the data representation of remote objects will be done much like 
the Brand-based synergy in KeyKOS to rights-amplify a Start key into a 
Domain key.  If you have further questions about what this means after 
looking at this issue in KeyKOS, I'll try to answer.

For the above reason, control-flow debugging can only span vats for which 
you have this superuser-like authority to be part of their TCB.


>So it is possible we will see the distributed
>debugger before the hijacked debuggers 

Another reason this is true is that the hijacking requires compiling E to 
JVM bytecodes & debugging info in the form that stock Java debuggers expect. 
 While there's nothing conceptually hard about this, it's a lot of work that 
no one's yet signed up to do.

The distributed debugger, by itself, views each individual turn as atomic, 
and is concerned instead about the partially order causal structure of 
message -> turn -> messages.  We should be able to write this with minimal 
dependencies of the way E is implemented.


>(though the distributed debugger may
>well enter the world as a commercial product, not open sourceware).

Grump.  Quibble.  Open source software are often commercial products.


>>3. How secure are the Miranda methods?  Has it been determined that
>>it's safe to give out type information, etc. to anyone possessing a
>>capability?

I believe it's safe to give it out *by default*, for the reasons MarcS 
explains.  However, it would be a violation of the capability model if such 
automatically-calculated type information were given out without the object 
itself having a say in the matter.  That's why all the Miranda methods are 
overridable.

In addition, there's the experimental "Plumbing Expression" ( 
http://www.erights.org/elang/blocks/defPlumbing.html and 
http://www.erights.org/elang/kernel/PlumbingExpr.html ) for letting you 
waive your Miranda rights.


>>4. What's "poE" (mentioned in MirandaMethods.java)?
>
>markm will have to answer when he's out of the closet.

"Partially Ordered E".  No longer a relevant term, and should be removed 
from the docs.  It dates from when we made a transition (fiercely resisted by 
me at first) from an Actor like unordered messages delivery semantics to the 
current semantics.


>>It would be awfully nice if the E site and list archive were indexed,
>>by the way, so that I could easily tap into materials on various
>>subjects (such as the above)
>
>Yes. We all dream of better organized Web sites. An extremely high
>priority...
>as soon as v1.0 of E is in the can. So it will be several months before this
>is improved.

In the meantime, the Google advanced search page 
http://www.google.com/advanced_search lets you search within a web site.  
The following link (if put back together into a single line) will give you 
all mentions of "foo" within the "www.erights.org" site.

http://www.google.com/search?as_q=foo&num=10&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_occt=any&as_dt=i&as_sitesearch=www.erights.org&safe=off

Ok, back in the closet... ;)


        Cheers,
        --MarkM