Thank you Norman very much answering all my questions.
1- Is there anyway that a child can be endowed with any extra capabilities to server services at creation by its parent?....
At start time of a new child, the parent provides the child with only one capability that we call parent capability. ..... Do you see the need to statically preconfigure the environment of a child with a set of capabilities?
No, I don't see any need for the parent to be able endow a set of capabilities at creation. (I was just checking to see that I understood the new child creation process properly. Some other cap theory and projects websites I've previously looked at mention or have endowment at creation so was wondering if genode could do this as well)
2- In the documentation it says that the parent of a server ...
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. ..... Then however, RAM allocations are not anymore individually accountable to those processes.
Thanks for clearing this up for me. I did wonder a bit about the memory quota sharing implications and thought that there might be problems like you've outlined.
Just out of curiosity, do you see a practical case for sharing a root capability among multiple processes?
No, I don't. (Please note though that I don't think I'm in a position to give much opinion cause I've only just started learning about genode- also I'm only a amateur/hobbyist so my opinions don't count for much sorry)
3- The documentation mentions the use of unix file permissions. ....
The use of UNIX file permissions .... In fact, we do not plan to introduce UNIX file permissions into the base framework of Genode.....
I'm very happy/relieved to here this :) (As a suggestion -although from an amateur- perhaps you should specifically mention that ACL's/unix file permissions are not intrinsic to genode nor are they planned to be. Because on first pass reading I go the impression that the file permissions might be planned although it is a cap based system-- and I was reading it from the perspective of someone familiar with cap theory and knows the difference between caps and ACLs. I feel that if someone who read this wasn't already familiar cap OSes and all they knew were traditional ACL systems then they would assume that the file permissions are indeed already present and necessarily intrinsic.)
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. .....
This sound very interesting!
Thanks once again for answering, but if you don't mind can I bother you with just few more last questions: A: Two questions regarding the interfaces between parent and child- 1) How does a server to signal to the client that it will need/does need more quota. (The interface methods given in the "Interfaces and Mechanisms" document allows a client to give quota to a server, but hows does the client know when and how much it needs to give?)
2)Are the session request strings expected to follow a format and naming standard for common types of services?
B:Other questions- 1)Do you eventually intend to formally verify the software? (I believe the NICTA /OK-labs L4 kernel that genode can target is in the process of being verified and was wondering if you will likewise wish to verify genode to supply a fully mathematically verified framework for building OS personalities on).
Lastly, I re-read the "Interfaces and Mechanisms" and I think I've found another minor error- in the section "Quota" in the sentence "Once, the server requests to close the session, the child is responsible to release all resources that were used for this session.". Aren't the words "server" and "child" meant to be swaped around here?
Thanks Ross McGinnis
_________________________________________________________________ Get the latest news, goss and sport Make ninemsn your homepage! http://windowslive.ninemsn.com.au/article.aspx?id=813730
Hi Ross,
I'm very happy/relieved to here this :) (As a suggestion -although from an amateur- perhaps you should specifically mention that ACL's/unix file permissions are not intrinsic to genode nor are they planned to be. Because on first pass reading I go the impression that the file permissions might be planned although it is a cap based system-- and I was reading it from the perspective of someone familiar with cap theory and knows the difference between caps and ACLs. I feel that if someone who read this wasn't already familiar cap OSes and all they knew were traditional ACL systems then they would assume that the file permissions are indeed already present and necessarily intrinsic.)
You are right, the section "Successive policy management" may be misleading. I just wanted to use Unix file permissions as an example, but certainly, it is better to avoid this reference. I will try to find a more general example.
Thanks once again for answering, but if you don't mind can I bother you with just few more last questions: A: Two questions regarding the interfaces between parent and child-
- How does a server to signal to the client that it will need/does
need more quota. (The interface methods given in the "Interfaces and Mechanisms" document allows a client to give quota to a server, but hows does the client know when and how much it needs to give?)
That is a very good point. At present, the resource requirements of the currently implemented services are pretty static. We use to transfer quota at session-creation time and do not (yet) need to use a subsequent 'tranfer_quota' call at all. But how does a client know, how much quota to donate? This information is actually provided as a part of the service's interface definition in the form of a 'Connection' class that comes along with the server's RPC-interface classes. For example, the Nitpicker GUI server requires the client to donate a memory quota dependent on the size of the pixel buffer to use. The corresponding 'Connection' class is located at
os/include/nitpicker_session/connection.h
and encapsules the heuristics about how much resources are to be donated when creating a session with a certain buffer size. Thereby, the application programmer does not need to care about that. He just opens a session to Nitpicker by constructing a 'Nitpicker::Connection' object
static Nitpicker::Connection nitpicker(width, height);
and interacts with the server via member functions of the created object, for example
nitpicker.refresh();
However, the service discovery and resource negotiation are still subject for improvement in the future.
2)Are the session request strings expected to follow a format and naming standard for common types of services?
The arguments are service specific. The only naming standard is the use of a comma-separated list of <tag>=<value> pairs and the character set to be used for tags and values. However, the meaning of tags depends on each server - very much like command line arguments of Unix programs depend on the actual program. There are some arguments that are interpreted by the parent and should be used in the intended way, for example 'ram_quota' specifies the memory quota, the child is going to donate to the server, or 'label' holds an optional textual label for the session. But in general, these arguments are optional and regarded as untrusted by the parent. However, in order to implement a least-priviledge policy in the parent, the parent will have to know the services and their arguments and filter session arguments according to the policy.
B:Other questions- 1)Do you eventually intend to formally verify the software? (I believe the NICTA /OK-labs L4 kernel that genode can target is in the process of being verified and was wondering if you will likewise wish to verify genode to supply a fully mathematically verified framework for building OS personalities on).
Currently, we do not pursue such plans. The seL4 verification project by OK-Labs/NICTA is exciting but it also shows the tremendous amount of effort and expertise that is needed for such a project. Actually, the complexity of the Genode framework is in the same range as the code used in the seL4 project, which allows a rough estimation of the feasibility and costs of verifying the framework's code. However, in contrast to seL4, the Genode framework is multithreaded. As far as I know, multi- threading is not addressed by the seL4 project (and I suppose, this is for a good reason).
Lastly, I re-read the "Interfaces and Mechanisms" and I think I've found another minor error- in the section "Quota" in the sentence "Once, the server requests to close the session, the child is responsible to release all resources that were used for this session.". Aren't the words "server" and "child" meant to be swaped around here?
Technically, "child" is correct because the server is actually a child but I clearly see your point. ;-) Thanks for the hint - I am going to change the wording to be less confusing.
Best regards Norman
Norman Feske wrote:
and interacts with the server via member functions of the created object, for example
nitpicker.refresh();
...just noticed that this is a bad example since there does not exist a 'refresh' function in Nitpicker's interface. ;-) I would have better picked one of the functions actually declared in 'nitpicker_session.h'.
Norman
-
Norman Feske -
ross mcginnis