[EROS-Arch] The Environment Problem

[Jonathan S. Shapiro]

> 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.

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.

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.

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.

> >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.

If the constructor itself supplies the space bank verifier key and the
metaconstructor key to the yield, then it is of course an alternative
constructor is in a position to specify an alternative set as the ones to
trust.

> Perhaps with machines
> costing less than $1,000,000, people would prefer to dedicate a machine to
> [testing in parallel].

As I outlined above, I don't think that we are actually at that point here,
but even if we are, VMware is pretty cheap. :-)

> >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'm not fully convinced of that. All of the items in case (3)
are discrete, so there is no security motivation on the part of the creator
to preclude their transfer. Depending on how things are set up, the yield
might only need to trust the system installer to populate this space in good
faith, and might *not* need to worry that the creator may have inserted
malicious code of their own into the name space, because the namespace is
not (in general) under the creator's control.

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.

> 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.

I think we are using the term "creator" differently. By "creator", I mean
the program that invoked the constructor requestor key that caused this
object to be created. The new object needs to trust its developer. It needs
to trust the constructor. It needs to trust the creator for durability. It
need not necessarily trust the creator to provide its component
environment -- this depends on how the system structure is designed.

What do *you* mean by creator?

> On the other hand, an object needs to be given the tools to test objects
> that are passed to it after the creation process...

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.

> 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.

Okay. I'm definitely confused, since my terms the creator is the immediate
caller. Perhaps I should switch terms. Can you define creator?

Thanks for all your comments, by the way!


Jonathan