[EROS-Arch] The Environment Problem

[Bill Frantz]

At 5:51 PM -0700 9/24/01, Jonathan S. Shapiro wrote:
>> For short-lived domains, passing these keys in well-known capability
>> registers saves the cost of the fetch...
>
>Some of them, as it turns out, need to go into well-known registers anyway
>for use by protospace.

If these register assignments are part of the API, a significant part of
the cost will go away.


>The concern I have here is one of future extensibility. We are shortly going
>to reach the point where the number of things conveyed by the spacebank puts
>significant pressure on the register set. The problem is that if we don't
>plan now for future extensibility we may face the need for a later
>incompatible change.
>
>> In addition, for such domains, the cost of
>> the spacebank operations to create the separate node can be significant.
>
>On some architectures, I agree, but because of the larger node size, the
>issue doesn't arise in EROS as much as in KeyKOS. Every current 32-bit
>architecture except SPARC can go into a single node. The majority of 64-bit
>architectures (again excepting SPARC) can also go into single nodes until
>you want a floating point unit. Most architectures can be fit into two
>nodes, leaving the third for the proposed use.

As the number of things conveyed increases, there will be an increasing
cost for storing the individual keys as an instance is created.  If many of
these things are the same for all instances (the space bank verifier and
metaconstructor are examples), then a shared read-only/sensory node can
reduce this cost.  The tree-oriented node fetch proposal will limit the
cost of fetching from the extra node.

>
>Charlie has proposed that processes should be fabricated by the space bank,
>discarding the process creator. If this is done then the efficiency of node
>allocation becomes a much less important issue.

Good point.


>In any case, I'm less concerned about ultimate performance at this point
>than I am about long-term engineerability, but I also appreciate the point
>you are making here.

I think we are in agreement.  If there is a problem in the end, it is
always possible to have two paths for object creation that know and trust
each other.


>> >TRUST ISSUES FOR THE NEW OBJECT
>> >
>> >One of the things that always bugged me about KeyKOS was the fact that
>you
>> >had to trust the system administrator to give you a couple of keys: the
>> >space bank verifier and the metaconstructor....
>>
>> KeyKOS was designed to allow safe replacement of these basic system
>> components by the general user....
>
>I don't think that this proposed change alters that significantly. It seems
>to me that the constructor, metaconstructor, and space bank have quite an
>intimate little arrangement going. It does not seem unreasonable to me to
>say that if you want to experiment with a new and different space bank
>design you may also need to implement (or at least recompile) the
>constructor triad. These are primordial objects, and it makes some amount of
>sense that they should replace as a unit.

As a practical matter, I think you had to replace all three in KeyKOS if
you wanted to play with changing any one of them.


And for the rest, I suspect that most of our mutual confusion is brought on
by different meanings for the terms.  I had assumed that the creator was
the person/process which defined the class.  I.e. the detailed steps by
which the object is created.  (I would use "requestor" for the
person/process which causes instances to be created.)  You made it obvious
that you meant the creator as being the person/object requesting an
instance.  Is "developer" your preferred term for the class definer?


>In the trusted path case matters are somewhat different, because the trusted
>path is *not* discrete, and therefore needs to be permitted by the user.
>Unfortunately, in the window system case it also needs to be dynamically
>bound at run time rather than compile time, which means that it cannot be
>provided to the application by prior arrangement. In this case what we have
>is a situation where the creator must say that access to the object is okay,
>but the yield might not trust the creator to provide the actual object.
>
>I *think* this can be handled by providing a distinguished key to a
>constructor that allows the wielder to ask "is this process your yield" but
>does NOT convey the ability to fabricate a new yield from that constructor.
>This key should NOT be considered a hole. Placing such a verifier key in the
>discrete namespace may then be enough to conquer the trusted path problem.

Agreed.


>Indeed. And for any such decision that can be resolved at install time,
>static binding works fine for this. However, if you want to do dynamic
>binding then the yield needs access at least a namespace of verifier keys.

Probably a separate thread, but it seems to me that dynamic binding of
libraries is a can of worms for reliability and security on current systems.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA