Hi Ross,

thanks for your interest in our project and your thoughtful questions.

1- Is there anyway that a child can be endowed with any extra capabilities to server services at creation by its parent? Or is it always the case that the child always has to be first created without any extra capabilities and only after it is created then can it gain external caps by requesting a service by way of its parent?

At start time of a new child, the parent provides the child with only one capability that we call parent capability. Using this single capability, the child can then request all further capabilities as needed. It is up to the policy of the parent to answer these requests or not. This way, the interface between parent and child are as minimalistic as possible at the start time of the child. Do you see the need to statically preconfigure the environment of a child with a set of capabilities?

2- In the documentation it says that the parent of a server is given the root_capability to any services announced by the child and this cap is intended to be used and kept by the parent only. Is this cap actually copyable and transferrable? And does it really matter if the parent gives this cap away? This last question may seem really dumb since it goes against the whole point of having an acylic tree of parent to children nodes to facilitate reasoning about the TCB, however, if you haven't actually stopped the parent from been able to give it away shouldn't you assume that it will give it away?

In fact, it is just a decision of the parent to keep the root capability. A root capability could be transferred to another protection domain via IPC just like any other capability. But if the parent handed out the root capability to a third party, it would loose control over the policy enforced through the session arguments when a new session of the service gets created by the third party. This would be against its own interest but Genode does not enforce him to keep the root capability private. Maybe there are useful scenarios for which a root capability is shared among multiple processes, for example if a group of processes behave cooperatively but still want to isolate faults via address-space protection. However, so far we have always ended up with organizing such groups as a hierarchy and separating the duties of the processes such that each root capability is guarded by only one process. Furthermore, the mechanism for lending memory from a client to a server requires the creator of the service's RAM session to transfer quota to the service. Normally, it is the service's parent who own capabilities to both, the service's RAM session and its own RAM session. If multiple processes would share a root capability, all those processes should also share the same RAM session to be able to supply resources to the service when creating sessions. Then however, RAM allocations are not anymore individually accountable to those processes.

Just out of curiosity, do you see a practical case for sharing a root capability among multiple processes?

3- The documentation mentions the use of unix file permissions. Are access control lists and file permissions to be planned/implemented in the file servers within the genode project? If they are, it is there a possibility for a confused deputies to arise since the clients request services by using serive_name and arg strings instead of capabilities? From what I naively understand about capability based OSes is that you either have to provide a persistent state mechanism or an ACL like regime to be able to recreate the capability network at power-up after shut-down/crash-recovery. Is it possible for a system to be built using genode framework which is orthognally persistent and thus drop the use of ACL's?

The use of UNIX file permissions was just meant as an example for the successive restriction of policies. In fact, we do not plan to introduce UNIX file permissions into the base framework of Genode. Of course, a file server could implement them - with all implications such as the mentioned confused-deputy problem.

Right now, Genode creates the capability network dynamically at the system's boot time according to the policy of each involved parent. So there is no central ACL but the policy is distributed among all nodes that play a parent role. This approach neither requires persistency nor a statically configured ACL. In Genode, we do not attempt to establish one global scheme for handling file permissions. Different sub systems may implement different policies.

Lastly, I think there is a very slight mistake in the "Interfaces and Mechanisms" document in the "Servers" section towards the very end in the sentence "The session capability, created by Child1 (4), can now be passed to Child1 as return value of nested session calls (5, 6).": shouldn't the second mention of "Child1" actually be "Parent2"?)

You are right. Thank you very much for pointing this out. I have corrected the mistake on the website.

Best regards Norman