[EROS-Arch] The Environment Problem

[Bill Frantz]

At 12:27 PM -0700 9/23/01, Jonathan S. Shapiro wrote:
>PASSING THE ENVIRONMENT
>
>In actuality, there are two distinct environments here. One consists of
>items supplied by the constructor. These are trustworthy by virtue of the
>system design, and not by virtue of being supplied by the object's creator.
>Items 1 through 7 fall into this category. At present, these items are
>delivered to the application in well-known capability registers. In
>abstract, this mechanism is adequate, but the capability registers will soon
>start to run out, and I have come to feel that they should be passed in a
>separate node. This node should be allocated out of the same space bank that
>the yield is allocated from.

For short-lived domains, passing these keys in well-known capability
registers saves the cost of the fetch.  (It probably also saves the cost of
the store during construction.)  In addition, for such domains, the cost of
the spacebank operations to create the separate node can be significant.
YMMV


>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. The constructor needs both of
>these anyway, and you'll note that I've moved them into the
>constructor-supplied environment, where the system administrator can't screw
>with them in the absence of offline disk forensics.

KeyKOS was designed to allow safe replacement of these basic system
components by the general user.  The obvious use would be to test new
versions in parallel with normal system operations.  Perhaps with machines
costing less than $1,000,000, people would prefer to dedicate a machine to
such testing.


>NAME BINDING
>
>Name binding devolves into three distinct problems:
>
>1. The simple binding of names (strings) to capabilities. This can basically
>be handled by a directory.
>2. The problem that a component may not wish to trust it's creator in
>certain cases, but must nonetheless obtain trusted interfaces. I think of
>this as the "trusted path" problem. For example, a component may not trust
>its caller to supply the source for the "open file" dialog box.
>3. The problem of dynamic binding -- how can the executing code know that
>the namespace of constructors from which it instantiates things has not been
>tampered with (i.e. the namespace tampered with, not the constructors). The
>concern here is that the instantiating component would be ill-advised to
>give outward communication channels to an arbitrary piece of code.

2 and 3 seem to be two ways of describing the same problem.


>At the moment, I think that I understand how to do everything except the
>name binding part, and I'ld really appreciate comments and thoughts on this.

An object needs to trust it's creator, because the creator has complete
control over the object, including any code it might use to test its
components.  In a very real sense, the things provided by the creator are
the object's TCB.

On the other hand, an object needs to be given the tools to test objects
that are passed to it after the creation process.  That is the
responsibility of the objects designer/programmer to specify and the
creator to implement.  For example, an open file dialog box object could be
tested against a creator-provided test oracle.  (But in most cases, except
for promptness issues, the file object provided by the open file dialog
would be the thing that needed testing.)

It seems to me that you need every object to have a minimum of 2 name
spaces.  One for things from the creator, and at least one for things
passed by the various callers.  The name syntax doesn't matter, it can be
strings, or node slot numbers, or anything else, but the separation of name
spaces is fundamental to the capability model.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | My heart goes out to   | Periwinkle -- Consulting
(408)356-8506         | those directly affected| 16345 Englewood Ave.
frantz@pwpconsult.com | by the 9/11/01 attack. | Los Gatos, CA 95032, USA