TPM, Haskell and RPC mapped through NOVA
Norman Feske
norman.feske at ...1...
Thu Nov 20 11:29:45 CET 2014
Hi Thomas,
> Considering the amount of work that would be needed, I think I don't
> have the resources for that at the moment. I will stay with Xen as
> hypervisor for now.
no problem. :-)
> Out of interest, is there a way to merge Genode and Xen? Xen allows dom0
> disaggregation where device drivers are packed with a server backend in
> unprivileged, isolated VMs, which seems very similar to resource
> multiplexers in Genode I think. QEMU is also separated into individual
> VMs for each guest OS. The complexity of dom0 reduces at the same time,
> so it seems as Xen would be moving towards a micro kernel approach as
> well? A clear difference for me is that e.g. Genode allows a better
> capability and resource management at the moment.
>
> So in your opinion, where do you see clear differences between Genode
> and the future Xen?
I think the main difference are the starting points of both projects.
Xen is a hypervisor platform in the first place and seems to gradually
move towards componentization wherever it seems sensible. In contrast,
Genode is designed as component-based operating system that happens to
also support virtualization. Compared to the approaches I know from Xen,
the granularity of Genode's componentization is extremely fine. In fact,
there are over 100 components that can be combined to compose systems
out of. From the security point of view, the most distinctive
characteristic of Genode is a much lower TCB complexity. A Xen-based
system has to rely on the complex Xen hypervisor and the Linux system
that runs as Dom0. In contrast, Genode-based systems do not require a
DomU at all and can run on kernels that are as small as 10,000 lines of
code (NOVA). This makes the trusted computing base of such systems
orders of magnitude less complex.
> Would it be possible to bring the advantages of Genode over to Xen?
I believe so. In principle, I could envision three approaches:
* Supporting Xen as a kernel for Genode and use Xen's domains as
Genode's protection domains. However, this would require a
significant amount of work and the chance for creating synergies
between the Xen community and Genode is very little. Also, I do not
see any technical advantage of using Xen as kernel over NOVA.
* Using Genode as a replacement of Dom0. This would benefit Xen by
drastically reducing the TCB complexity of Xen-based systems compared
to the current use of Linux. The main problem here is moving the
existing Xen tools from Linux to Genode. There must be a clear
incentive to do that.
* Using Genode as a DomU. Instead of using multiple MiniOSes for
executing components, Genode could be used to host components and let
them interact with each other. Still, selected functionalities could
reside in separate VMs. So there would be a migration path. To kick
off work in this direction, the NOVA version of Genode could be used
in a DomU as is. Then, a set of user-level device drivers for Xen's
inter-domain communication facilities must be developed to connect
the Genode world with the Xen world.
> Would it be possible to run Xen enabled applications directly on the
> Genode framework?
Could you please be more specific about the applications you refer to?
Cheers
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
More information about the users
mailing list