At 11:31 AM -0700 6/11/97, Jonathan S. Shapiro wrote:
>In thinking further about the process/capage split, I stumbled on a
>question about the domain tool.
>
>It seems to me that the domain tool serves two essentially separate
>functions:
>
> 1. Provides ability to amplify a capability so as to
> destroy a domain
Or debug it.
> 2. Provides mechanism to brand a process.
Handled in KeyKOS by zapping a space bank.
>
>The first translates straightforwardly into the new picture, but the
>second doesn't. I am considering two possible replacement mechanisms,
>and would appreciate opinions:
>
>Mechanism 1: Anyone holding a domain key can change the brand slot IFF
> the slot's current value is DK(0).
>
>Mechanism 2: Anyone holding a domain key can change the brand slot.
>
>Mechanism 3: Anyone holding domain tool, domain/gate key, and previous
> brand can set new brand or obtain domain key. Mostly equivalent to
> (1), but more paranoid.
>
>... This incidentaly resolves the issue of being unable to destroy a
>domain whose domain creator has been blown away.
>
>There are several reasons for a process to be unable to make up
>somebody else's brand key. Are there reasons that a process should
>not be able to alter it's own brand?
Well, a brand is like a type in strongly typed languages. Should an object be able to change it's type? What happens if a program verifies the type of an object, and then it is changed?
On the other hand, when a factory is sealed, the valid operations change, although it is still the same domain. It might be reasonable to reflect this change as a change of type. (If might be cleaner if the key with the old authority were "destroyed", i.e. programmed to look like a null key; and a key with the new authority returned.) YMMV.
Bill Frantz | The Internet was designed | Periwinkle -- Consulting (408)356-8506 | to protect the free world | 16345 Englewood Ave. frantz@netcom.com | from hostile governments. | Los Gatos, CA 95032, USA