I have just come up with the anticipated example where read-only translucency would create a problem in EROS. It violates the isInstanceOf() mechanism. My comment may make more sense after you look at the EROS brand mechanism in the note that I will publish very shortly.
This particular example has an easy fix, but where there is one there will soon be two. Suppose I use my storage to obtain a ProcessCreator. Ultimately, the only purpose of a ProcessCreator is to support isInstanceOf(). Everything else that it does is pure convenience. The important property of a ProcessCreator is that it holds one capability that nobody else can read. This capability is used to label all processes created by this process creator. This is kind of like branding a cow (which is why we call the capability the "brand" and the slot in the process state the "brand slot"). There is no operation on a process capability that allows brand slot to be examined or modified. This means that a process cannot alter its brand. Later, the process creator can check whether it created a given process. There is a kernel service ProcessTool that implements an operation identify(ProcessCap,OtherCap)=>Bool this returns true exactly if OtherCap matches the capability stored in the brand slot of the Process that is named by ProcessCap. This check is fairly important: It prevents me from handing you a process that runs one program and claiming that it runs another (more mechanism is needed, but this is the underlying means of implementation). ProcessCreator instances also *destroy* processes. The brand prevents me from using *my* ProcessCreator to destroy *your* process. The problem is that the ProcessCreator was built with my storage. This means that I can inspect it, which means that I can extract the secret brand capability. The ability to extract the brand capability means that I can violate the integrity of the process type system. If this integrity is violated, the foundational chain of trust is broken because even the *primordial* servers cannot be reliably identified. Now in this particular case the "fix" is very simple. The function of ProcessCreator should have been done in the storage allocator in the first place. Separating out the ProcessCreator functionality seemed like a good idea when it was done but probably was not in hindsight. But the thing is: where there is one example there will turn out to be two. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
