newbie questions

[Norman Feske]

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