This essay argues that the Domain/Process creator and the space bank are essentially not independent and should be merged.
(Note: The syntax "A/B" refers to the concept of which A is the KeyKOS
name and B is the EROS name.)
Obviously the design must meet the usual engineering criteria; it must provide a useful function, and its implementation must be efficient. That is one level, the level of the kernel implementation.
On a more abstract level, the design must meet certain criteria that ensure that the security model etc. are consistent with the design philosopy of KeyKOS/EROS. This is the theoretical level. (I'm working on writing more about this level.)
On a more practical level, the design must be extensible. It is not possible to provide all possible functionality in the kernel. The design of KeyKOS/EROS provides a means for ordinary users to extend the functionality of the system by writing their own objects that can replace the basic kernel objects. These user objects can have the same interface as the kernel objects. This is the extensible level. I will call the kernel-implemented objects "real" objects, to distinguish them from "extended" objects.
Normally, it is unnecessary, and poor design, to verify that an offered key is what you expect it to be; greater flexibility and orthogonality are achieved when programs accept a key based on what it does rather than what it is. But there are three legitimate reasons for verifying a space bank: discretion, promptness, and use in domains.
For example, suppose an object provides a compilation service using a compiler whose algorithms are secret. The client provides the program to be compiled, and provides a space bank which the compiler uses for temporary storage. Suppose the client provided the audited extended space bank described above. From the logs of what was stored in the nodes and pages, detailed information about the operation of the compiler could be obtained. To prevent this, the compilation service verifies that the proffered bank is official and therefore known to be discreet.
Most servers want assurance that the creation of space for the new domain/process is reasonably prompt, so one client can't make the service unavailable to subsequent clients. Clearly an extended bank might simply never return. To avoid this, the server verifies that the proffered bank is official and known to be prompt.
Thus, the official Domain/Process Creator is fundamentally interrelated with the official space bank.
Note that this essay does not discuss any unofficial domain/process-like
objects that do not enjoy special treatment by the kernel.
A space bank would have a new operation, "Create a domain/process". It would return a domain/process key to a domain/process made from space of this bank.
The "Create a domain/process" operation would take a key to be used as the "brand" of the domain. Normally a bank is obligated to not give out the same domain/process key to anyone else, but the "brand" provides an exception, as detailed below.
Another operation is "rights amplification". It takes a key to be amplified and a brand key. If the key to be amplified is a start key to a domain created out of space recognized by this bank, with a brand equal to the passed brand, then the operation returns a domain key to that domain, and the dataByte/capabilityInformation of the start key.
This operation is compatible with the theoretical foundations of KeyKOS/EROS. The space bank can in principle save a copy of each domain key it has given out. It can create all possible start keys from those domain keys. It can compare the key to be amplified with all of those keys, and if there is a match, check the brand and return the corresponding information.
I assert that rights amplification can be efficiently implemented by the real space bank, using the domain tool, which it would closely hold.
The above phrase "space recognized by this bank" is a recognition of the likely implementation(s), both real and extended (see below), and is compatible with theory if we assume that the bank can communicate with its related banks.
Similar operations provide rights amplification for return, fault, and domain keys. I need to think more about rights amplification for segments and meters whose keeper is one of the keys whose rights can be amplified.
Normally, the creator of a domain would provide as a brand a key that no one else can obtain (such as a key to a private object, or a key from the unique key creator). Otherwise, others could perform rights amplification on the domain, and it would have little privacy. But, there is no requirement that the brand be private.
Part of an extended domain is a real domain, which will execute at full speed except when invoking keys. An extended domain key could be a start key to an intermediary domain that implements the domain operations and also (for example) audits calls. An extended start key could be a start key to another intermediary domain that audits calls to the extended domain. Likewise an extended resume key would be a resume key to another intermediary domain. These intermediary domains can implement any desired policies. They must insert additional intermediaries in front of keys given to the extended domain, in order that an intermediary can be inserted in front of the resume keys that are produced when the domain executes call invocations.
How would rights amplification work? The intermediary domains have a
brand that is private to the extended space bank. (This is necessary so
the extended space bank can maintain the integrity of its illusion.) When
asked to amplify rights, the extended space bank first uses its real underlying
space bank to amplify rights, using the extended bank's private brand.
If this succeeds, it tells the extended space bank that the proffered key
is to an object recognized by this bank. Then, using internal structures,
the extended space bank checks the proffered brand.
Meters present a problem similar to domains. Since EROS SchedClasses don't use space from a bank, this discussion applies to KeyKOS; it may apply to a future EROS design.
In the current design, it is possible to allocate a node from a space bank, use that node as a segment node in the address space of a process, create a meter key from the node, and simultaneously use the meter in the process. The kernel, let alone an extended space bank, doesn't support this properly. (The node can't be simultaneously prepared as a segment and a meter, so the process will make no progress.)
Here again the solution is to define a new type of object supported by the space bank, a meter object. The space bank would support a new operation to allocate a meter object and return a strong key to it, capable of controlling the meter. From the strong key one could create a meter key that can be used to run. The NODE_MAKE_METER_KEY operation on a KeyKOS node key would be eliminated. Again, extension is by means of an intermediary keeper.
The kernel could associate the type of a node (segment, meter, or domain
component) with the node, because a given node could have only one type.
This might simplify some delicate kernel logic that checks for nodes with
Nevertheless, this proposal is important because it eliminates two unnecessary object types (the DC/PC and DCC/PCC), merges objects that have no theoretical or practical reason to be separate, and enables more efficient storage of domains/processes.
Copyright 2000 Charles