[Squeak-e] Re: [e-lang] capabilities in Mozart-Oz

[Mark S. Miller]

[I've cross posted to users at mozart-oz.org in addition to e-lang and squeak-e.]

At 03:42 PM 6/8/2003  Sunday, Fred Spiessens wrote:

>Hi All,
>
>For a research project at UCL Belgium I am investigating capabilities to 
>enable secure programming in multi-paradigm languages. The Mozart 
>implementation of the Oz language will be my main research tool.
>I have to decide now whether or not to build a rough emulation of the 
>E-language mechanisms in Oz first and learn from that, or just go ahead in 
>Oz, and concentrate on the differences with E.
>1. Any advice from the subscribers on this mailinglist, regarding this 
>decision?
>Any particular reasons why you'd choose for the one or the other, or why you 
>think I should?


The E *language* (libraries aside) is secure not so much from the creation 
of new mechanisms, as from leaving out of those non-object non-lambda 
non-logic mechanisms (like global variables) that break security. The common 
ancestor of E and Mozart, Concurrent Prolog, was already capability secure 
without initially even realizing it, simply by staying clean enough to not 
destroy the capability security inherent in their computational model. The 
same was almost true of Scheme -- Jonathan Rees had to do very little to 
Scheme to make W7. (Though the story isn't quite as dramatic, as Scheme 
descends from Actors, and Actors were explicitly designed to be capability 
secure.)

The rights amplification pattern in Mozart is too weak. This may be the 
one area where you should think about adding rather than subtracting 
primitives from Mozart. (Though, depending on your concurrency, rights 
amplification may not need any additional primitives.)

Any effort you spend thinking about equality primitives will be well spent. 
This is an area of deceptive subtlety. Equality and rights amplification are 
also intimately related to each other. There are many possible stances on 
both in addition to E's, but if you go it afresh, don't underestimate these 
issues.

Think hard about modules and import. I expect E will turn to Mozart for 
guidance here. E's module system demonstrates some essential properties, but 
so far I consider it a failed experiment. (From what I've seen, I think 
Mozart is headed in a good direction here.)

The situation with the libraries is unlikely to be so happy. Ideally, the 
libraries are designed from scratch according to POLA principles. The 
needed factoring according to distinctions of authority does not happen 
accidentally, even in very clean systems. If you're stuck with a large 
legacy of old code you can't afford to rewrite, then see 
http://www.erights.org/elib/legacy/ . But taming will never be as good as a 
rewrite according to capability principles.


So my recommendation is, on the language design front, start with Oz, 
making it capability secure by removing all questionable primitives. For 
example, is Mozart serialization written in Mozart, or is it primitive? If 
it's written in Mozart, does it use any questionable primitives? Could it be 
written in Mozart without use of any questionable primitives? If not why 
not? (Btw, it would be useful to me for the paper I'm writing to know the 
answers to these particular questions.)

Make a list of *all* primitives. Those that can be rewritten with full 
equivalence purely in Mozart are effectively not primitive -- if you're 
right about this equivalence, then they're just optimizations. Of those that 
remain, any one may blow your security. Think hard about each, and remove 
all that you can.

On the libraries, whether you're building from scratch or taming, study 
the E or Waterken libraries first and emulate the lessons found there. (E 
and Waterken are the only extensive object-language-oriented libraries I 
know of designed from the ground up according to capability principles.)
In the end, you will spend much more work on secure library design than 
secure language design.


>2. It is claimed that Promise-based concurrency is important in E for 
>security. Do you think it's also important for capabilities in any way?

"A language for writing secure programs must first of all be a language for 
writing reliable programs." From
http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000017.html

See also http://www.eros-os.org/pipermail/e-lang/2003-February/008502.html

Btw, Mozart also has promise-based concurrency -- Mozart's logic variables 
and E's promises both descend from Concurrent Prolog's logic variables. I 
suspect the difference is that E maintains Concurrent Prolog's (and Actors) 
event-loop orientation whereas, if I understand, Mozart abandoned it.

E's contribution to concurrency (due to E's original creator, Doug Barnes) 
was to reconcile the promise + event loop orientation of the Concurrent 
Prolog and Actor traditions with sequential programming in the imperative 
tradition. No previous language I'm aware of in the promise + event loop 
style had a sequential-imperative programming sublanguage.


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

        Cheers,
        --MarkM