At Sun, 30 Apr 2006 21:45:07 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > Marcus: > > I have a technical question concerning your proposal. It appears to me > that there is a missing piece of case analysis here. I am not sure > whether it matters for what you are trying to ask, so I would appreciate > clarification. > > You wrote, in part: > > > (2) In this window of time, there is a point in time where the > > instantiated process has at least one capability that the > > instantiating process does not have. (_Any_ capability counts). > > In general, there are two types of "private" capabilities that the new > process might hold: > > A) (Transitively) read-only capabilities. These might include, for > example, the capability to the program's initial code image. > > B) Capabilities that permit communication outward. In the EROS > Constructor, this could be technically outside of your definition; > in order to authorize this, the instantiating process must hold > a "bag" containing this capability, but the bag is opaque. This > means that the instantiating process cannot *use* this capability. > > In case (A), I am not sure if the distinction here matters for the > purposes of your question. Assuming that the capabilities are > transitively read only, they are *completely* equivalent to stating that > the program holds a large constant number that is unknown (but in > principle available) to the instantiating process. However, without the > consent of the new process, there is no way to *confirm* which number > the new process holds. > > I am not sure if this distinction is relevant, and I would appreciate > clarification about whether you really intend such a transitively > read-only capability to "count".
I think they count, just as I stated. > In case (B), I believe that this sort of "opaquely held" capability > should count as a capability that the instantiating process does not > have -- though I am not certain of this. There are handshake protocols > here that could probably prevent DRM without going as far as you > suggest, and I would like to explore these alternatives more carefully. > > But for the moment, can you also clarify how the capabilities of case B > fit into your definition? They also count as capabilities that the instantiating process does not have, if they are only opaquely held by the instantiator. However: If they allow communication outward, then that means they violate rule (3), because some behaviour by the instantiated process (namely, an invocation of such a capability), can be observed by a process not directly (or indirectly, in the way I explained) authorized by the instantiator. The program is not confined in the sense of rule (3). I had to add rule (3), because I needed to exclude non-confined system services that spawn worker processes. Tentatively, I think the bags are really only necessary to fix up problems that pop up when you start with a non-bag use case, if that is true than starting with an empty bag does not pose a serious limitation of the case analysis. If you have a more interesting use case for bags, we can run this outside the competition ;) The meaning of the challenge, as proposed, is actually a very simple one: The claim is that a strictly hierarchical process tree based on the simple parent-child relationships is expressive enough for the Hurd. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
