At 11:45 9/14/95 -0400, Jonathan Shapiro wrote:
>Bill:
>
>Given your description of the domain tool in KeyKOS, it sounds like
>there may be a plausible alternative design:
>
>1. A domain is constructed by handing the domain tool a node that will
> become the domain root. This node must already have proper nodes
> in the general keys and general registers slots, and in the 68k
> implementation a page in whatever slot that was.
>
> The domain tool rescinds outstanding keys to all these objects.
>
>2. No operation on the domain tool allows the gen keys or gen regs
> slots to be altered once a domain is created.
>
>If it is done this way, then I *think* that the kernel doesn't need to
>trust the holder of the domain tool any more than before, but some
>consistency checks can safely be removed from the domain prepare code
>in the kernel.
I think that this design would work. However, there is still a class of kernel bugs that would be caught by the consistancy checks.
>
>The down side is that it precludes domains from sharing the general
>keys node. I think this may be a good thing.
>
It turns out that sharing the general keys node is not too hard in a UP
implementation. It might be harder in an MP however.
>
>Or did the KeyKOS kernel design protect itself against the possibility
>that the party who originally handed the node key to the domain tool
>might retain a node key to the domain root? If the object keys are
>rescinded to prevent this, are any problems caused?
The only way to use a domain tool in KeyKOS was through the DomainCreator. The kernel did not trust the DomainCreator (since it was outside the kernel), but in practice, it was trustworthy. It took calls of the form:
DomainCreator(Create;SpaceBank==>c;Domain)
Since it did not pass any of the node keys outside, the node keys were in effect contained.
Bill