Hello Norman, Thank you for your advice. I will continue my experiment.
Have you compared the performance of an unmodified Genode system (e.g., qt5.run) with VSOS? I have compared the performance of an unmodified Genode system (both 13.02 and 14.08) and VSOS both on qemu and real machine. The performance of them are similar which cannot satisfy our team leader/my advisor. He thought that it should be faster for apps on Genode (all operations should be finished at once), but both unmodified Genode and VSOS cannot satisfy him. He thought the problem may be related to inter-process communication between Init and ,or interaction between Qt and other parts of Genode, but I don't find out the problem in these aspects.
How are you testing VSOS (Qemu or real hardware)? Yes, we have tested VSOS on real hardware for a long time in order to publish a distribution. It's really faster on real machine, but they still think it's too slow.
Shuo Wang, University of Chinese Academy of Sciences.
------------------ 原始邮件 ------------------ 发件人: "norman.feske";<norman.feske@...1...>; 发送时间: 2014年9月10日(星期三) 晚上6:34 收件人: "genode-main"genode-main@lists.sourceforge.net;
主题: Re: Answers of some questions about performance optimization relatedto GUIframework on Genode
Hi Shuo Wang,
unfortunately, I am extremely busy this and next week. So I could not experiment with VSOS.
Thanks for considering my comments. However, you left a few of my questions unanswered:
Have you compared the performance of an unmodified Genode system (e.g., qt5.run) with VSOS?
How are you testing VSOS (Qemu or real hardware)?
- It seems to introduce the notion of global IDs, which Genode tries to avoid to counter problems like "ambient authority".
There are no global IDs. The IDs are used to mark the task in mandatory access control, which is implemented in Monitor.
I think that implementing MAC by calling a policy module per RPC call at user level is misguided. If a process possesses a capability, it has by definition the right to access the resource referred-to by the capability because the capability was delegated to the process beforehand. Delegation implies the granting of the access right.
In a capability-based system, capabilities cannot be created out of thin air. In order to use a capability, someone has to delegate it first. The access-control (or better validity) check is done by the kernel (on kernels that support capability-based security) each time a capability is used.
Since a process owns no capabilities (except for the parent capability) when started, each capability possessed by the process has already passed the security policy by the originator of the capability when it was delegated. So the access is authorized.
Instead of designing your system such that you need to check a MAC rule database for critical capability invocations, just don't delegate critical capabilities in the first place.
- With my limited understanding of your changes, it looks like your group implemented a classical ACL-policy mechanism right into the heart of Genode. In my opinion, this approach contradicts with the Genode's capability-based access-control model. I would love to know the rationale behind this line of work and discuss possible alternative solutions that are coherent with Genode's design.
The capability-based access-control model is similar to DAC model. We implemented a "Monitor" following MAC.
I suspect that you slightly misunderstand the idea behind capability-based security. If used as intended (i.e., separating different security concerns at the granularity of different capabilities), no global "Monitor" with an all-encompassing policy database is needed.
- The code path is performance-critical, yet it performs slow string compare operations and RPC calls.
Maybe too many "connections" slow down the system. Would you like to give some advice on performance improvement on Qt5? Even the mouse cursor in the system cannot move fluently.
I'd like to assist if you have serious performance issues with the unmodified Genode system. But please do not expect me to debug performance issues that were introduced by your massive patch. To find out whether the performance problems come from Genode or your patch, please compare the performance of VSOS against the performance of an unmodified Genode scenario.
As a general hint for investigating where the CPU time goes, you might explore the Fiasco.OC kernel debugger. Using the "lp" command, you can obtain a list of threads and their state. A stuttering mouse cursor may be caused by a busy-looping thread (caused by a bug?). So first look for the "ready" threads in the list. Furthermore, the kernel debugger is able to print the amount CPU time used per thread (in the screen that appears after selecting a thread). This may provide you with a first indication of where the CPU time is consumed. Please refer to the manual of the Fiasco kernel debugger [1] for more information. Unfortunately, it is a bit out of date (written for the original L4/Fiasco kernel) but most information is still applicable on Fiasco.OC.
[1] http://os.inf.tu-dresden.de/fiasco/doc/jdb.pdf
Best regards Norman