doc: update of challenges.txt
This commit is contained in:
parent
a58b2a1e9f
commit
5b2e909062
|
@ -16,18 +16,16 @@ research projects on Genode.
|
||||||
Applications and library infrastructure
|
Applications and library infrastructure
|
||||||
#######################################
|
#######################################
|
||||||
|
|
||||||
:Chrome web browser:
|
:GNU Privacy Guard:
|
||||||
|
|
||||||
The Chrome web browser promises to address the most pressing security
|
The [https://gnupg.org/ - GNU Privacy Guard] (GNUPG) is the most widely
|
||||||
concerns of web application by isolation measures, in particular the
|
used Free-Software implementation of the OpenGPG standard. It comprises a
|
||||||
sandboxing of plugins and the confinement of individual web applications. As
|
rich set of tools for encryption and key management. For many forthcoming
|
||||||
we demonstrated with the Genode Live CD 10.11, Genode facilitates a more
|
application scenarios of Genode such as package management and email
|
||||||
natural way to pursue such techniques compared with current commodity
|
communication, GNUPG is crucial. Hence, it should be ported to Genode. Such
|
||||||
operating systems. Furthermore, the use of Genode as base platform for Chrome
|
a port may leverage Genode's fine-grained component architecture to strongly
|
||||||
would strengthen the web-browser security by dwarfing its trusted computing
|
separate network-exposed functionality, the storage of key material, and the
|
||||||
base by two orders of magnitude compared to the use of Linux as base
|
cryptographic functions.
|
||||||
platform. This would allow Chrome to be considered as a secure interface to
|
|
||||||
the web for use cases in the high-assurance domain.
|
|
||||||
|
|
||||||
:VNC server implementing Genode's framebuffer session interface:
|
:VNC server implementing Genode's framebuffer session interface:
|
||||||
|
|
||||||
|
@ -41,6 +39,17 @@ Applications and library infrastructure
|
||||||
the network. One immediate application of this implementation is the remote
|
the network. One immediate application of this implementation is the remote
|
||||||
testing of graphical Genode applications running on a headless server.
|
testing of graphical Genode applications running on a headless server.
|
||||||
|
|
||||||
|
:Interfacing with the SAFE network:
|
||||||
|
|
||||||
|
The [https://safenetwork.org/ - SAFE network] is an attempt to fix many
|
||||||
|
shortcomings of the internet - in particular with respect to privacy and
|
||||||
|
freedom - at an architectural level. It is a peer-to-peer communication
|
||||||
|
and storage network that does not depend on single point of
|
||||||
|
failure or control. It is intriguing to explore the opportunity of
|
||||||
|
integrating support for the SAFE network not merely as an application but
|
||||||
|
integrated in the operating system, i.e., in the form of Genode components
|
||||||
|
or a set of Genode VFS plugins.
|
||||||
|
|
||||||
:Tiled window manager:
|
:Tiled window manager:
|
||||||
|
|
||||||
At Genode Labs, we pursue the goal to shape Genode into an general-purpose
|
At Genode Labs, we pursue the goal to shape Genode into an general-purpose
|
||||||
|
@ -73,33 +82,11 @@ Applications and library infrastructure
|
||||||
support for real-time priorities, this base techniques enable the creation of
|
support for real-time priorities, this base techniques enable the creation of
|
||||||
flexible audio mixer / switchboard applications, which require dedicated
|
flexible audio mixer / switchboard applications, which require dedicated
|
||||||
frameworks (e.g., Jack audio) on traditional operating systems. The goal of
|
frameworks (e.g., Jack audio) on traditional operating systems. The goal of
|
||||||
this project is to create a show case implementation demonstrating the
|
this project is to create a showcase implementation demonstrating the
|
||||||
feasibility for creating high-quality audio applications on Genode.
|
feasibility for creating high-quality audio applications on Genode.
|
||||||
Furthermore, we wish for feedback regarding the current design of our bulk
|
Furthermore, we wish for feedback regarding the current design of our bulk
|
||||||
streaming interface when used for low-latency applications.
|
streaming interface when used for low-latency applications.
|
||||||
|
|
||||||
:PDF reader for E-Government use:
|
|
||||||
|
|
||||||
A facility for reading PDF and E-Book documents is one of the indispensable
|
|
||||||
features Genode has to provide to be considered for general-purpose
|
|
||||||
computing. The goal of this work is to identify a suitable open-source PDF
|
|
||||||
engine and port it as native application to Genode. The challenging part is
|
|
||||||
to keep the complexity of this application as low as possible in order to
|
|
||||||
enable the use of this application as a trusted document reader. Further
|
|
||||||
ideas envision the use of PDF files as medium for sensitive documents
|
|
||||||
combined with measures for protecting the integrity of the displayed
|
|
||||||
information. For example, when processing contracts or similar sensitive
|
|
||||||
documents in E-Government scenarios, the consumer of such documents expects
|
|
||||||
the correct display of all the information as expressed by the creator of the
|
|
||||||
document. In the event of a compromised PDF engine or a man-in-the middle
|
|
||||||
attacker manipulating the PDF file, the consumer of the document requires a
|
|
||||||
way to identify such security breaches. In this context, running the PDF
|
|
||||||
engine in a sandboxed Genode subsystem has two incentives. First, the attack
|
|
||||||
surface for manipulating the PDF engine gets dramatically reduced, and
|
|
||||||
second, the integrity of the result of the PDF engine can be measured by an
|
|
||||||
independent trusted component facilitating Genode secure GUI server
|
|
||||||
(Nitpicker).
|
|
||||||
|
|
||||||
:Graphical on-target IPC tracing tool using Qt:
|
:Graphical on-target IPC tracing tool using Qt:
|
||||||
|
|
||||||
Analysing the interaction of components of a multi-server operating system
|
Analysing the interaction of components of a multi-server operating system
|
||||||
|
@ -129,180 +116,86 @@ Applications and library infrastructure
|
||||||
of communicating threads as captured on the running system. The tool should
|
of communicating threads as captured on the running system. The tool should
|
||||||
work on a selected kernel that provides a facility for tracing IPC messages.
|
work on a selected kernel that provides a facility for tracing IPC messages.
|
||||||
|
|
||||||
|
:Ports of popular software:
|
||||||
|
|
||||||
Application frameworks
|
Genode features a ports mechanism to cleanly integrate 3rd-party software.
|
||||||
######################
|
Thanks to the C runtime, the flexible per-component VFS, the standard
|
||||||
|
C++ library, and the Noux runtime (for UNIX software), porting software
|
||||||
:Running the Meego application stack on Genode using Qt:
|
to Genode is relatively straight forward. The
|
||||||
|
[http://genode.org/documentation/developer-resources/porting - porting guide]
|
||||||
With Genode 11.02, Qt has become available. The most prominent feature
|
explains the typical steps. A wish list of software that we'd like to
|
||||||
of this version is the new QML language to design GUIs using a declarative
|
have available on Genode is available at
|
||||||
language. This technique is targeted specifically to mobile applications and
|
[http://usr.sysret.de/jws/genode/porting_wishlist.html].
|
||||||
other touch-based devices. The goal of this project is to run the Meego
|
|
||||||
application stack natively on Genode. First, the software components and
|
|
||||||
Meego-specific Linux customizations must be identified. For each such
|
|
||||||
component, it must be decided whether to port its code or to reimplement its
|
|
||||||
interface. The immediate goal of the first step is running one Meego example
|
|
||||||
application natively on Genode.
|
|
||||||
|
|
||||||
:Python Qt bindings:
|
|
||||||
|
|
||||||
With the Python interpreter and the port of the Qt framework, the principle
|
|
||||||
components for Python-based GUIs on Genode are available. However, the glue
|
|
||||||
between both components is missing. The incentive of this work is supplementing
|
|
||||||
our Python port with the modules needed for real applications and porting the
|
|
||||||
Qt bindings to Genode. This would bring Genode one step closer to executing
|
|
||||||
modern Python-based GUI applications (in particular KDE4 applications).
|
|
||||||
|
|
||||||
:Evaluation of porting GTK+ to Genode:
|
|
||||||
|
|
||||||
With Qt, we have demonstrated the feasibility to run a highly-complex
|
|
||||||
application framework via Genode on a wide range of microkernels. That leaves
|
|
||||||
the question of looking into the other major toolkit in town, namely GTK+ as
|
|
||||||
used by Firefox and the Gnome desktop.
|
|
||||||
|
|
||||||
:Cairographics:
|
|
||||||
|
|
||||||
Cairo is a high-quality 2D vector graphics engine used by a large number of
|
|
||||||
open-source projects, in particular GTK+. Hence the port of Cairo is a
|
|
||||||
prerequisite for the GTK+ challenge. In addition, it would enable the
|
|
||||||
use of further libraries such as Poppler.
|
|
||||||
|
|
||||||
|
|
||||||
Device drivers
|
Application frameworks and runtime environments
|
||||||
##############
|
###############################################
|
||||||
|
|
||||||
:Enhancing Gallium3D support:
|
:OpenJDK:
|
||||||
|
|
||||||
Genode 10.08 introduced Gallium3D including the GPU driver for Intel GMA
|
[http://openjdk.java.net/ - OpenJDK] is the reference implementation of the
|
||||||
CPUs. With this initial version, we demonstrated that the powerful software
|
Java programming language and hosts an enormous ecosystem of application
|
||||||
stack for running hardware-accelerated 3D applications can be deployed on
|
software. The goal of this line of work is the ability to run this
|
||||||
Genode. At the same time, it motivates us to reach out for even more
|
software directly on Genode. The centerpiece of OpenJDK is Hotspot - the
|
||||||
ambitious goals:
|
Java virtual machine implementation, which must be ported to Genode.
|
||||||
|
The initial port should suffice to execute simple example programs that
|
||||||
|
operate on textual input. Since Genode has the FreeBSD libc readily
|
||||||
|
available, OpenJDK's existing POSIX backends can be reused. The next step
|
||||||
|
is the creation of Genode-specific native classes that bridge the gap
|
||||||
|
between the Java world and Genode, in particular the glue code to
|
||||||
|
run graphical applications as clients of Genode's GUI server. Since
|
||||||
|
OpenJDK has been ported to numerous platforms (such as Haiku), there
|
||||||
|
exists a comforting number of implementations that can be taken as
|
||||||
|
reference.
|
||||||
|
|
||||||
First, the current approach executes the GPU driver alongside the complete
|
:Android's ART VM natively on Genode:
|
||||||
Gallium3D software stack and the application code in one address space. To
|
|
||||||
enable the use of multiple hardware-accelerated applications running at the
|
|
||||||
same time, the GPU driver must run separated from the Gallium3D code as done
|
|
||||||
on Linux. The preliminary interfaces for this decomposition are already in
|
|
||||||
place but there are several open questions. Most importantly, the page-fault
|
|
||||||
handling of buffer objects mapped in the application's address space.
|
|
||||||
|
|
||||||
Second, we'd like to complement our current Intel GMA GPU driver with
|
ART is a Java virtual machine that is used for executing applications on
|
||||||
interrupt-based synchronization, namely vblank handling. This requires an
|
Android. By running ART directly on Genode, the Linux kernel could be
|
||||||
understanding of the Intel GMA interrupt code and the enhancement of our
|
|
||||||
driver environment.
|
|
||||||
|
|
||||||
Third, we desire the use of further Gallium3D drivers, in particular the
|
|
||||||
Nouveau and r300 drivers. The basic approach to bring these drivers to Genode
|
|
||||||
is the same as for Intel GMA but the respective driver environments are yet
|
|
||||||
to be developed.
|
|
||||||
|
|
||||||
If you are interested in low-level graphics hacking, GPUs, and
|
|
||||||
high-performance graphics, this project is ideal to get you on track.
|
|
||||||
|
|
||||||
:Split USB core from USB device drivers:
|
|
||||||
|
|
||||||
Genode's current USB support is based on the Linux USB stack running as a
|
|
||||||
single process on Genode. This process includes the USB core logic, USB host
|
|
||||||
controller driver as well as the USB device drivers such as HID or USB
|
|
||||||
storage. This monolithic USB process is rather inflexible. Hence, we desire a
|
|
||||||
decomposition of this solution such that the USB host driver and each USB
|
|
||||||
device driver runs in a separate process.
|
|
||||||
|
|
||||||
:I/O Kit:
|
|
||||||
|
|
||||||
I/O Kit is the device-driver framework as used by the Darwin operating
|
|
||||||
system, which forms the basis for Mac OS X. The port of I/O Kit would enable
|
|
||||||
the easy re-use of the library of I/O-Kit-based device drivers on Genode. As
|
|
||||||
foundation of this project, we recommend to use the DDE Kit API featured by
|
|
||||||
Genode.
|
|
||||||
|
|
||||||
:Support for multi-touch input devices:
|
|
||||||
|
|
||||||
The efforts towards enabling mobile application stacks such as Meego and
|
|
||||||
Android on Genode must be accompanied by a revision of Genode's 'Input'
|
|
||||||
session interface to accommodate multi-touch input devices. First, existing
|
|
||||||
APIs such as multi-touch support in X11, Qt, and Android should be analysed.
|
|
||||||
Based on these findings, we expect a proposal for changing Genode's input
|
|
||||||
interface. The interface extension should be validated by a example driver
|
|
||||||
implementing the interface as well as an example applications.
|
|
||||||
|
|
||||||
|
|
||||||
System services
|
|
||||||
###############
|
|
||||||
|
|
||||||
:Copy-on-write memory manager:
|
|
||||||
|
|
||||||
Genode's managed dataspaces provide a generalized page-table concept,
|
|
||||||
enabling servers to provide on-demand paged memory objects (dataspaces) to
|
|
||||||
clients. This concept is showcased by the ISO9660 driver, which provides
|
|
||||||
on-demand paged ROM dataspaces to its clients. Depending on the access
|
|
||||||
pattern of the client, the ISO9660 server loads the used parts of the ROM
|
|
||||||
file from CDROM. Managed dataspaces principally allow for a wide variety of
|
|
||||||
interesting applications such as the transparent migration of non-local and
|
|
||||||
local memory in a NUMA system, sparse dataspaces, swapping, and copy-on-write
|
|
||||||
dataspaces. The goal of this project is a dataspace manager that implements
|
|
||||||
copy-on-write semantics combined with a merging technique optimizing the
|
|
||||||
memory footprint at runtime. Pages of two managed dataspaces that share the
|
|
||||||
same content should be provided via read-only page sharing. If one client
|
|
||||||
attempts to change the content of a shared page, a new physical copy of the
|
|
||||||
page get created. Vice versa, if the content of different pages converge, the
|
|
||||||
sharing should be re-established. This work is a follow-up of the diploma
|
|
||||||
thesis of Sebastian Sumpf
|
|
||||||
[http://os.inf.tu-dresden.de/papers_ps/sumpf-diplom.pdf - Cloning L4Linux].
|
|
||||||
On the course of this project, the managed dataspace concept of Genode
|
|
||||||
will be refined, in particular regarding the creation of read-only
|
|
||||||
dataspaces from read-write dataspaces.
|
|
||||||
|
|
||||||
:Using Haskell as systems-development language:
|
|
||||||
|
|
||||||
The goal of this project is the application of functional programming
|
|
||||||
i.e., Haskell, for the implementation of low-level Genode components.
|
|
||||||
Implementing critical functionalities in such a high-level language instead
|
|
||||||
of a classical systems language such as C or C++ would pave the way towards
|
|
||||||
analyzing such components with formal methods.
|
|
||||||
|
|
||||||
The use of Haskell for systems development was pioneered by the
|
|
||||||
[http://programatica.cs.pdx.edu/House/ - House Project]. A more recent
|
|
||||||
development is [http://halvm.org - HalVM] - a light-weight OS runtime for
|
|
||||||
Xen that is based on Haskell.
|
|
||||||
|
|
||||||
:Dbus emulation:
|
|
||||||
|
|
||||||
Dbus is a popular inter-process communication mechanism on Linux, which
|
|
||||||
enables user applications to respond to global system events and announce
|
|
||||||
state changes to other applications. It is extensively used by modern desktop
|
|
||||||
environments. To enable such applications to integrate well with Genode, a
|
|
||||||
Dbus emulation solution has to be developed.
|
|
||||||
|
|
||||||
:Wayland:
|
|
||||||
|
|
||||||
With the availability of Gallium3D on Genode, the prospect for incorporating
|
|
||||||
further projects of the Linux graphics ecosystem into Genode arises.
|
|
||||||
[http://wayland.freedesktop.org - Wayland] is a window server especially
|
|
||||||
designed to be used with Gallium3D. Its design has many similarities with
|
|
||||||
Genode's Nitpicker GUI server, in particular the decision to move window
|
|
||||||
handling policies to the client and thereby minimize the complexity of the
|
|
||||||
GUI server. Whereas Nitpicker was designed for high security, Wayland is
|
|
||||||
targeted to creating GUIs with fluid and tearless animations using
|
|
||||||
hardware-accelerated graphics. We believe that because of the many conceptual
|
|
||||||
parallels with Nitpicker, Wayland would fit very well into the Genode system.
|
|
||||||
However, as a prerequisite for this project, Genode's Gallium3D support must
|
|
||||||
be decomposed first. See the challenges regarding our Gallium3D support for
|
|
||||||
further information.
|
|
||||||
|
|
||||||
|
|
||||||
Runtime environments
|
|
||||||
####################
|
|
||||||
|
|
||||||
:Android's Dalvik VM natively on Genode:
|
|
||||||
|
|
||||||
Dalvik is a Java virtual machine that is used for executing applications on
|
|
||||||
Android. By running Dalvik directly on Genode, the Linux kernel could be
|
|
||||||
removed from the trusted computing base of Android, facilitating the use of
|
removed from the trusted computing base of Android, facilitating the use of
|
||||||
this mobile OS in high-assurance settings.
|
this mobile OS in high-assurance settings.
|
||||||
|
|
||||||
|
:Rust bindings for the Genode API:
|
||||||
|
|
||||||
|
Rust is a low-level systems programming language that ensures memory
|
||||||
|
safety without employing a garbage collector. It thereby challenges C++
|
||||||
|
as the go-to programming language for high-performance and low-level code.
|
||||||
|
Since
|
||||||
|
[http://genode.org/documentation/release-notes/16.05#New_support_for_the_Rust_programming_language - version 16.05],
|
||||||
|
Genode supports the use of the Rust programming language within
|
||||||
|
components. However, to unleash the potential of this combination,
|
||||||
|
Genode's API must become available to native Rust code. The intermediate goal
|
||||||
|
of this project is the implementation of an example server, e.g., a
|
||||||
|
component that provides a terminal-session interface. Thereby, we
|
||||||
|
will encounter the problems of bootstrapping and configuration of the
|
||||||
|
component, the provisioning of signal handlers and session objects, and
|
||||||
|
memory management.
|
||||||
|
|
||||||
|
:Go language runtime:
|
||||||
|
|
||||||
|
Go is a popular language in particular for web applications. In the past,
|
||||||
|
there were numerous attempts to make the Go runtime available on Genode
|
||||||
|
but so far, none of those undertakings have landed in the official
|
||||||
|
Genode source tree. To goal of this project is the hosting of
|
||||||
|
Go-written applications - in particular networking applications - as
|
||||||
|
Genode components. The topic comprises work on the tool-chain
|
||||||
|
and build-system integration, the porting the runtime libraries, and
|
||||||
|
the glue between the Go and Genode environments.
|
||||||
|
|
||||||
|
:Combination of CAmkES with Genode:
|
||||||
|
|
||||||
|
[https://wiki.sel4.systems/CAmkES - CAmkES] is a component framework for
|
||||||
|
seL4. In contrast to Genode, which is a dynamic system, CAmkES-based systems
|
||||||
|
are defined at design time and remain fixed at runtime. Hence, CAmkES and
|
||||||
|
Genode can be seen as the opposite ends of component-based used-land
|
||||||
|
architectures. The goal of this project is to build a bridge between
|
||||||
|
both projects with the potential to cross-pollinate the respective communities.
|
||||||
|
Among the principal approaches are embedding of a single CAmkES
|
||||||
|
component as a Genode component (e.g., an individual device driver),
|
||||||
|
the hosting of a dynamic Genode system as a component within a
|
||||||
|
CAmkES system, or the hosting of a CAmkES system composition as a Genode
|
||||||
|
subsystem.
|
||||||
|
|
||||||
:Runtime for the D programming language:
|
:Runtime for the D programming language:
|
||||||
|
|
||||||
The D systems programming language was designed to overcome many gripes that
|
The D systems programming language was designed to overcome many gripes that
|
||||||
|
@ -316,23 +209,141 @@ Runtime environments
|
||||||
programs, and interfacing D programs with other Genode components written in
|
programs, and interfacing D programs with other Genode components written in
|
||||||
C++.
|
C++.
|
||||||
|
|
||||||
|
:Using Haskell as systems-development language:
|
||||||
|
|
||||||
|
The goal of this project is the application of functional programming
|
||||||
|
i.e., Haskell, for the implementation of low-level Genode components.
|
||||||
|
Implementing critical functionalities in such a high-level language instead
|
||||||
|
of a classical systems language such as C or C++ would pave the way towards
|
||||||
|
analyzing such components with formal methods.
|
||||||
|
|
||||||
|
The use of Haskell for systems development was pioneered by the
|
||||||
|
[http://programatica.cs.pdx.edu/House/ - House Project]. A more recent
|
||||||
|
development is [http://halvm.org - HalVM] - a light-weight OS runtime for
|
||||||
|
Xen that is based on Haskell.
|
||||||
|
|
||||||
|
|
||||||
|
Virtualization
|
||||||
|
##############
|
||||||
|
|
||||||
|
:VirtualBox on top of KVM on Linux:
|
||||||
|
|
||||||
|
Genode's version of VirtualBox replaces the original in-kernel VirtualBox
|
||||||
|
hypervisor by the virtualization mechanism of the NOVA hypervisor or the
|
||||||
|
Muen separation kernel. Those mechanisms look very similar the KVM
|
||||||
|
interface of the Linux kernel. It should in principle be possible to
|
||||||
|
re-target Genode's version of VirtualBox to KVM. This way, VirtualBox and
|
||||||
|
Qemu/KVM-based virtual machines could co-exist on the same system, which
|
||||||
|
is normally not possible. Also, complex Genode scenarios (like Turmvilla)
|
||||||
|
could be prototyped on GNU/Linux.
|
||||||
|
|
||||||
|
:VirtualBox on top of seL4:
|
||||||
|
|
||||||
|
The [https://sel4.systems - seL4 microkernel] is a modern microkernel that
|
||||||
|
undergoes formal verification to prove the absence of bugs. Since version
|
||||||
|
4.0, the kernel supports virtualization support on x86-based hardware.
|
||||||
|
Genode has experimental support for seL4 that allows almost all Genode
|
||||||
|
components to be used on top of this kernel. VirtualBox is an exception
|
||||||
|
because it closely interacts with the underlying kernel (like NOVA) to
|
||||||
|
attain good performance. We have shown that VirtualBox can be executed
|
||||||
|
within a protection domain of the NOVA microhypervisor. The goal of this
|
||||||
|
project is the application of this approach to the virtualization
|
||||||
|
interface of seL4. The result will be a VM hosting environment that
|
||||||
|
ensures the separation of virtual machines via the formally verified
|
||||||
|
seL4 kernel.
|
||||||
|
|
||||||
|
:Xen as kernel for Genode:
|
||||||
|
|
||||||
|
Using Xen as kernel for Genode would clear the way to remove the
|
||||||
|
overly complex Linux OS from the trusted computing base of Xen
|
||||||
|
guests OSes.
|
||||||
|
|
||||||
|
Xen is a hypervisor that can host multiple virtual machines on one physical
|
||||||
|
machine. For driving physical devices and for virtual-machine management, Xen
|
||||||
|
relies on a privileged guest OS called Dom0. Currently, Linux is the
|
||||||
|
predominant choice to be used as Dom0, which implicates a trusted computing
|
||||||
|
base of millions of lines of code for the other guest OSes.
|
||||||
|
|
||||||
|
Even though Xen was designed as hypervisor, a thorough analysis done by Julian
|
||||||
|
Stecklina concludes that Xen qualifies well as a kernel for Genode. For
|
||||||
|
example, Julian implemented a version of Genode's IPC framework that utilizes
|
||||||
|
Xen's communication mechanisms (event channels and shared memory).
|
||||||
|
|
||||||
|
:Genode as virtualization layer for Qubes OS:
|
||||||
|
|
||||||
|
[https://www.qubes-os.org/ - Qubes OS] is a desktop operating system
|
||||||
|
that follows the principle of security through compartmentalization.
|
||||||
|
In spirit, it is closely related to Genode. In contrast Genode's
|
||||||
|
clean-slate approach of building a fine-grained multi-component system,
|
||||||
|
Qubes employs Xen-based virtual machines as sandboxing mechanism. In
|
||||||
|
[https://blog.invisiblethings.org/2015/10/01/qubes-30.html - version 3.0],
|
||||||
|
Qubes introduced a Hypervisor Abstraction Layer, which decouples Qubes
|
||||||
|
from the underlying virtualization platform. This exploration project
|
||||||
|
pursues the goal of replacing Xen by Genode as virtualization layer
|
||||||
|
for Qubes.
|
||||||
|
|
||||||
|
:Qemu:
|
||||||
|
|
||||||
|
As we use Qemu as primary testing platform for most of the kernels, a port
|
||||||
|
of Qemu to Genode is needed in order to move our regular work flows to
|
||||||
|
Genode as development platform. The basic prerequisites namely libSDL and a
|
||||||
|
C runtime are already available such that this porting work seems to be
|
||||||
|
feasible. In our context, the ia32, amd64, and ARM platforms are of most
|
||||||
|
interest. Note that the project does not have the immediate goal of
|
||||||
|
using hardware-based virtualization. However, if there is interest,
|
||||||
|
the project bears the opportunity to explore the provisioning of the
|
||||||
|
KVM interface based on Genode's VFS plugin concept.
|
||||||
|
|
||||||
|
|
||||||
|
Device drivers
|
||||||
|
##############
|
||||||
|
|
||||||
|
:Isochronous USB devices:
|
||||||
|
|
||||||
|
Genode's USB driver supports bulk and interrupt endpoints. Thereby, most
|
||||||
|
USB devices like USB storage, user input, printers, and networking devices
|
||||||
|
can be used. However, multi-media devices such as cameras or audio
|
||||||
|
equipment use isochronous endpoints, which are not supported. The goal
|
||||||
|
of this line of work is the support of these devices in Genode. The topic
|
||||||
|
touches the USB driver, the USB session interface, an example implementation
|
||||||
|
of a USB client driver (using the session interface) for a device of choice,
|
||||||
|
and - potentially - the enhancement of Genode's USB-pass-through mechanism
|
||||||
|
for VirtualBox.
|
||||||
|
|
||||||
|
:Sound on the Raspberry Pi:
|
||||||
|
|
||||||
|
The goal of this project is a component that uses the Raspberry Pi's
|
||||||
|
PWM device to implement Genode's audio-out-session interface. Since
|
||||||
|
Genode's version of libSDL already supports this interface as audio
|
||||||
|
backend, the new driver will make the sound of all SDL-based games
|
||||||
|
available on the Raspberry Pi.
|
||||||
|
|
||||||
|
:Framebuffer for UEFI and Coreboot:
|
||||||
|
|
||||||
|
By moving away from the legacy BIOS boot mechanism, it is time to
|
||||||
|
reconsider closely related traditional approaches such as the use of
|
||||||
|
the VESA BIOS extensions for accessing the frame buffer. On UEFI or
|
||||||
|
Coreboot systems, there exist alternative ways to initialize and
|
||||||
|
access the framebuffer in a hardware-independent way. On the course of
|
||||||
|
this project, we will explore the available options and create dedicated
|
||||||
|
Genode driver components that use the modern mechanisms.
|
||||||
|
For reference, the current state of Genode's UEFI support is documented
|
||||||
|
in [https://github.com/genodelabs/genode/issues/2242 - Issue 2242].
|
||||||
|
|
||||||
|
:Data Plane Development Kit (DPDK):
|
||||||
|
|
||||||
|
Genode utilizes the network device drivers of the iPXE project, which
|
||||||
|
perform reasonably well for everyday use cases but are obviously not
|
||||||
|
designated for high-performance networking.
|
||||||
|
The [http://dpdk.org/ - DPDK] is a vendor-supported suite of network device
|
||||||
|
drivers that is specifically developed for high-performance applications.
|
||||||
|
It presents an attractive alternative to iPXE-based drivers. This project
|
||||||
|
has the goal to make DPDK drivers available as a Genode component.
|
||||||
|
|
||||||
|
|
||||||
Platforms
|
Platforms
|
||||||
#########
|
#########
|
||||||
|
|
||||||
:Evaluation of MP scheduling models on different Genode base platforms:
|
|
||||||
|
|
||||||
Several of Genode's supported base platforms come with multi-processor
|
|
||||||
support, i.e., Linux, NOVA, L4ka::Pistachio, and Fiasco.OC. Each of
|
|
||||||
these kernels follows a different approach for utilizing multiple CPUs. For
|
|
||||||
example, Linux manages the association of threads with CPUs largely
|
|
||||||
transparent for user-level programs - not so for the available microkernels.
|
|
||||||
Furthermore, microkernels differ with reagrd to
|
|
||||||
thread migration and scheduling. The goal of this project is to identify ways
|
|
||||||
to support the SMP features of the respective kernels at Genode's API level
|
|
||||||
such that SMP can be easily utilized by Genode programs in a largely kernel
|
|
||||||
agnostic way.
|
|
||||||
|
|
||||||
:Microkernelizing Linux:
|
:Microkernelizing Linux:
|
||||||
|
|
||||||
Thanks to Genode's generic interfaces for I/O access as provided by core, all
|
Thanks to Genode's generic interfaces for I/O access as provided by core, all
|
||||||
|
@ -363,17 +374,6 @@ Platforms
|
||||||
Finally, this project has the potential to ignite a further collaboration
|
Finally, this project has the potential to ignite a further collaboration
|
||||||
between the HelenOS and Genode communities.
|
between the HelenOS and Genode communities.
|
||||||
|
|
||||||
:Support for the Barrelfish kernel:
|
|
||||||
|
|
||||||
[http://barrelfish.org - `Barrelfish] is a so-called multi-kernel OS designed
|
|
||||||
for heterogeneous multi-processor systems. At its heart, it is a
|
|
||||||
microkernel-based multi-server OS. Its kernel provides different mechanisms
|
|
||||||
than L4-based kernels. Instead of managing threads in the kernel, there is a
|
|
||||||
mechanism for implementing preemptive multi-threading at user level.
|
|
||||||
Consequently, inter-process communication does not address threads but
|
|
||||||
protection domains. This makes the Barrelfish kernel a very interesting and
|
|
||||||
challenging target for running Genode.
|
|
||||||
|
|
||||||
:Support for the XNU kernel (Darwin):
|
:Support for the XNU kernel (Darwin):
|
||||||
|
|
||||||
XNU is the kernel used by Darwin and Mac OS X. It is derived from the
|
XNU is the kernel used by Darwin and Mac OS X. It is derived from the
|
||||||
|
@ -381,22 +381,6 @@ Platforms
|
||||||
kernel is used for Mac OS X, it could represent an industry-strength
|
kernel is used for Mac OS X, it could represent an industry-strength
|
||||||
base platform for Genode supporting all CPU features as used by Mac OS X.
|
base platform for Genode supporting all CPU features as used by Mac OS X.
|
||||||
|
|
||||||
:Xen as kernel for Genode:
|
|
||||||
Using Xen as kernel for Genode would clear the way to remove the
|
|
||||||
overly complex Linux OS from the trusted computing base of Xen
|
|
||||||
guests OSes.
|
|
||||||
|
|
||||||
Xen is a hypervisor that can host multiple virtual machines on one physical
|
|
||||||
machine. For driving physical devices and for virtual-machine management, Xen
|
|
||||||
relies on a privileged guest OS called Dom0. Currently, Linux is the
|
|
||||||
predominant choice to be used as Dom0, which implicates a trusted computing
|
|
||||||
base of millions of lines of code for the other guest OSes.
|
|
||||||
|
|
||||||
Even though Xen was designed as hypervisor, a thorough analysis done by Julian
|
|
||||||
Stecklina concludes that Xen qualifies well as a kernel for Genode. For
|
|
||||||
example, Julian implemented a version of Genode's IPC framework that utilizes
|
|
||||||
Xen's communication mechanisms (event channels and shared memory).
|
|
||||||
|
|
||||||
:Linux process containers for supporting Genode`s resource trading:
|
:Linux process containers for supporting Genode`s resource trading:
|
||||||
|
|
||||||
Even though the Linux version of Genode is primarily meant as a development
|
Even though the Linux version of Genode is primarily meant as a development
|
||||||
|
|
Loading…
Reference in New Issue