Answers of some questions about performance optimization related to GUIframework on Genode

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth