Side-effect free containers for E

[Bill Frantz]

At 10:13 PM 8/15/00 -0700, Mark S. Miller wrote:
>At 02:21 PM 8/15/00 , Dean Tribble wrote:
>>At 07:06 PM 8/14/00 -0700, Mark S. Miller wrote:
>>The key approach in Joule is, of course, facets (each facet is a
different capability).  To design such that the write authority includes
the read authority, the write authority just has an operation to return the
read authority facet (which is a different capability).  This is cheap, and
syntactically non-painful, prevents the kind of security exposure we
discussed, and results in smaller interfaces.  (The result of smaller
interfaces is more polymorphism, more reusability, etc. but that's a
separate topic :-)
>
>The DT protocol follows this description exactly.  We see it has a cost.
>
>
>>This means that thinning as a strategy is to be avoided (in retrospect
:-)--it defines a supertype with less authority.  Instead, KeyKOS, etc.
should follow a strategy of facets in which the capability bits controls
which orthogonal set of operations can be invoked, and you can never have a
capability that allows invoking more than one of them.  Note that this does
not affect the overall architecture, but just how domains functions are
organized.
>
>And the protocols of the primitive capabilities exported from the Kernel.  
>I'm very curious how KeyKOS and EROS people will react to the proposal that 
>their protocols be redesigned in this manner.  Guys, please speak up!

Sorry, I was away for a week at a family reunion.

I guess from a KeyKOS perspective I react to the proposal of only one
facet/key with near violent hostility.  I think this reaction comes from
the difference between an operating system and a language.  In a language,
you can have an optimizer which optimizes the extra operations you have to
add to use the language based type system.

The experience of writing for KeyKOS was quite different.  As an OS, it
didn't have any optimizing phase, so those extra key invocations to get the
facets you need are real overhead.  This coupled with the always too few
key registers (16 on KeyKOS), means that this paradigm results in programs
that are significantly slower than the paradigm used by KeyKOS/EROS.

I think that the solution to this problem is to reexamine the type system
semantics to see if we can get semantics that naturally express the
operation thinning pattern.  (The standard OO type system seems best suited
to expressing an operation thickening pattern.)

Cheers - Bill