Hello,
I have an idea to run one Genode-Core over the another Genode-Core just like a simple genode application on a Fiasco.OC. I think it's possible and I have checked this opportunity on host-linux. I think it's interesting idea that provides the new isolation abstraction level of Genode like VM. I think that this idea demands some reducing of platform part of foc functionality. But I don't guess what difficulties it leads for. I don't know enough L4 api. Can you point out some possible problems/changes that have to be solved in order run one genode-core on another? Like changing pager of upper core or some others.
Regards, Ivan
Hello,
I'm trying to clear up how Genode service works. As I understand from hello_tutorial description on genode.org there is a magic "Server_entrypoint" object for serving sessions. But I noticed this object being used by Genode::Child too. What's the main idea of entrypoint object in Child class?
Alexander
Hello Ivan,
admittedly, I do not fully understand the motivation behind your idea. The most fundamental concept of Genode is its recursive structure - so each process already lives in a virtual environment provided by its parent. This is nested virtualization by heart. For example, look at the nested init example as 'os/config/nested_config'. In this example, init starts another instance of init as its child process and imposes a policy onto this new subsystem. From the perspective of the second init instance, everything (except for the customization of its policy) looks exactly like it was started directly by core.
This is just a trivial example. If you like, you could create a custom init-like program that virtualizes any of core's services. This approach is extensively applied by the 'loader' service as used by the web-browser demo featured on our last live CD.
Hence, I do not see the immediate benefit (neither for security nor for functionality) of running another instance of core on top of core. That said, I can imagine that your idea has a lot of hack value. So I don't want to keep you from going forward. :-)
One thing worth exploring would be the use of Fiasco.OC's VCPU feature to host another instance of Genode's core ontop of Genode - similar to how we run L4Linux ontop of Genode. The VCPU feature can be accessed via Genode's Fiasco.OC-specific extension of the PD and CPU session interfaces. This work would be quite challenging because you would need to implement the functionality normally provided by the microkernel within your paravirtualized core. This functionality comprises the management of a virtual TLB, a scheduler, and IPC. You may look at our custom 'base-mb' platform for inspiration.
Finally, let me direct you to our first live CD. The last boot-menu entry features the Linux version of Genode running on OKLinux, which in turn runs on the OKL4 version of Genode. Maybe, you will like it:
http://genode.org/download/live-cds#Genode_Live_Demonstration_2009-09
Cheers Norman
On 05/19/2011 04:39 PM, Ivan Bludov wrote:
Hello,
I have an idea to run one Genode-Core over the another Genode-Core just like a simple genode application on a Fiasco.OC. I think it's possible and I have checked this opportunity on host-linux. I think it's interesting idea that provides the new isolation abstraction level of Genode like VM. I think that this idea demands some reducing of platform part of foc functionality. But I don't guess what difficulties it leads for. I don't know enough L4 api. Can you point out some possible problems/changes that have to be solved in order run one genode-core on another? Like changing pager of upper core or some others.
Regards, Ivan
Hi Alexander,
On 05/20/2011 11:56 AM, Kiba Alexandra wrote:
I'm trying to clear up how Genode service works. As I understand from hello_tutorial description on genode.org http://genode.org there is a magic "Server_entrypoint" object for serving sessions. But I noticed this object being used by Genode::Child too. What's the main idea of entrypoint object in Child class?
a 'Server_entrypoint' is always needed if a process wants to dispatch RPC calls. Obviously this is the case for a server. But this also applies for each parent process. Such a process provides the 'Parent' interface (see: 'base/include/parent/parent.h') to each of its children. The 'Child' class implements this interface on the parent side. In the simplest case, this entrypoint is only used to dispatch RPC calls to the parent interface but in other cases, the parent may also provide locally implemented services via the same entrypoint. Please note that each child process has a dedicated entrypoint in the parent. So concurrent (possibly blocking) invokations of the parent interface by multiple children do not interfere.
Regards Norman
-
Ivan Bludov -
Kiba Alexandra -
Norman Feske