genode/doc/challenges.txt

                 =======================================
                 Future Challenges of the Genode project
                 =======================================


Abstract
########

This document compiles various ideas to pursue in the context of Genode. It is
meant as source of inspiration for individuals who are interested in getting
involved with the project and for students who want to base their student
research projects on Genode.


Applications and library infrastructure
#######################################

:GNU Privacy Guard:

  The [https://gnupg.org/ - GNU Privacy Guard] (GNUPG) is the most widely
  used Free-Software implementation of the OpenGPG standard. It comprises a
  rich set of tools for encryption and key management. For many forthcoming
  application scenarios of Genode such as package management and email
  communication, GNUPG is crucial. Hence, it should be ported to Genode. Such
  a port may leverage Genode's fine-grained component architecture to strongly
  separate network-exposed functionality, the storage of key material, and the
  cryptographic functions.

:VNC server implementing Genode's framebuffer session interface:

  With 'Input' and 'Framebuffer', Genode provides two low-level interfaces
  used by interactive applications. For example, the Nitpicker GUI server uses
  these interfaces as a client and, in turn, exports multiple virtual
  'Framebuffer' and 'Input' interfaces to its clients. This enables a
  highly modular use of applications such as the nesting of GUIs. By
  implementing the 'Framebuffer' and 'Input' interfaces with a VNC server
  implementation, all graphical workloads of Genode would become available over
  the network. One immediate application of this implementation is the remote
  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:

  At Genode Labs, we pursue the goal to shape Genode into an general-purpose
  operating system suitable for productive work. The feature set needed to
  achieve this goal largely depends on the tools and applications daily used by
  the Genode engineers. As one particularly important tool for being highly
  productive, we identified a tiled user interface. Currently, all developers
  at Genode Labs embrace either the Ion3 window manager or the tiled Terminator
  terminal emulator. Hence, we desire to have a similar mode of user
  interaction on Genode as well. The goal of this challenge is to identify the
  most important usage patters and the implementation of a tiled GUI that
  multiplexes the framebuffer into a set of tiled and tabbed virtual
  framebuffers.

  Related to this work, the low-level 'Framebuffer' and 'Input' interfaces
  should be subject to a revision, for example for enabling the flexible change
  of framebuffer sizes as needed by a tiled user interface.

:Interactive sound switchbox based on Genode's Audio_out session interface:

  Since version 10.05, Genode features a highly flexible configuration concept
  that allows the arbitrary routing of session requests throughout the
  hierarchic process structure. Even though primarily designed for expressing
  mandatory-access control rules, the concept scales far beyond this use case.
  For example, it can be used to run an arbitrary number of processes
  implementing the same interface and connecting the different interface
  implementations. One special case of this scenario is a chain of audio
  filters with each using the 'Audio_out' session interface for both roles
  client and server. Combined with the Nitpicker GUI server and Genode's
  support for real-time priorities, this base techniques enable the creation of
  flexible audio mixer / switchboard applications, which require dedicated
  frameworks (e.g., Jack audio) on traditional operating systems. The goal of
  this project is to create a showcase implementation demonstrating the
  feasibility for creating high-quality audio applications on Genode.
  Furthermore, we wish for feedback regarding the current design of our bulk
  streaming interface when used for low-latency applications.

:Graphical on-target IPC tracing tool using Qt:

  Analysing the interaction of components of a multi-server operating system
  such as Genode is important to discover bottlenecks of the system and for
  debugging highly complex usage scenarios involving many processes. Currently,
  Genode handles this problem with two approaches. First, Genode's
  recursive structure enables the integration of a subsystem in a basic
  OS setup featuring only those drivers and components used for the particular
  subsystem. After the successful integration of such a subsystem, it can
  be embedded into a far more complex application scenario without any changes.
  With this approach, the subject to analyse can be kept at a reasonable level
  at integration time. For debugging purposes, the current approach is using
  the debugging facilities of the respective base platforms (e.g., using
  GDB on Linux, the Fiasco kernel debugger, the OKL4 kernel debugger).

  However, in many cases, bottlenecks do not occur when integrating individual
  sub systems but after integrating multiple of such subsystems into a large
  application scenario. For such scenarios, existing debugging methodologies do
  not scale. A tool is desired that is able to capture the relationships
  between processes of a potentially large process hierarchy, to display
  communication and control flows between those processes, and to visualize the
  interaction of threads with the kernel's scheduler.

  Since Qt is available natively on Genode, the creation of both offline and
  on-target analysis tools has become feasible. The first step of this project
  is creating an interactive on-target tool, that displays the interaction
  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.

:Ports of popular software:

  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
  to Genode is relatively straight forward. The
  [http://genode.org/documentation/developer-resources/porting - porting guide]
  explains the typical steps. A wish list of software that we'd like to
  have available on Genode is available at
  [http://usr.sysret.de/jws/genode/porting_wishlist.html].


Application frameworks and runtime environments
###############################################

:OpenJDK:

  [http://openjdk.java.net/ - OpenJDK] is the reference implementation of the
  Java programming language and hosts an enormous ecosystem of application
  software. The goal of this line of work is the ability to run this
  software directly on Genode. The centerpiece of OpenJDK is Hotspot - the
  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.

:Android's ART VM natively on Genode:

  ART is a Java virtual machine that is used for executing applications on
  Android. By running ART directly on Genode, the Linux kernel could be
  removed from the trusted computing base of Android, facilitating the use of
  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:

  The D systems programming language was designed to overcome many gripes that
  exists with C++. In particular, it introduces a sane syntax for meta
  programming, supports unit tests, and contract-based programming. These
  features make D a compelling language to explore when implementing OS
  components. Even though D is a compiled language, it comes with a runtime
  providing support for exception handling and garbage collection. The goal of
  the project is to explore the use of D for Genode programs, porting the
  runtime to Genode, adapting the Genode build system to accommodate D
  programs, and interfacing D programs with other Genode components written in
  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
#########

:Microkernelizing Linux:

  Thanks to Genode's generic interfaces for I/O access as provided by core, all
  Genode device drivers including drivers ported from Linux and gPXE can be
  executed as user-level components on all supported microkernels. However, so
  far, we have not enabled the use of these device drivers on Linux as base
  platform. The goal of this project is the systematic replacement of in-kernel
  Linux device drivers by Genode processes running in user space, effectively
  reducing the Linux kernel to a runtime for Genode's core process. But moving
  drivers to Genode processes is just the beginning. By employing further
  Genode functionality such as its native GUI, lwIP, and Noux, many protocol
  stacks can effectively be removed from the Linux kernel.

  The goal of this project is to evaluate how small the Linux kernel can get
  when used as a microkernel.

:Support for the HelenOS/SPARTAN kernel:

  [http://www.helenos.org - HelenOS] is a microkernel-based multi-server OS
  developed at the university of Prague. It is based on the SPARTAN microkernel,
  which runs on a wide variety of CPU architectures including Sparc, MIPS, and
  PowerPC. This broad platform support makes SPARTAN an interesting kernel to
  look at alone. But a further motivation is the fact that SPARTAN does not
  follow the classical L4 road, providing a kernel API that comes with an own
  terminology and different kernel primitives. This makes the mapping of
  SPARTAN's kernel API to Genode a challenging endeavour and would provide us
  with feedback regarding the universality of Genode's internal interfaces.
  Finally, this project has the potential to ignite a further collaboration
  between the HelenOS and Genode communities.

:Support for the XNU kernel (Darwin):

  XNU is the kernel used by Darwin and Mac OS X. It is derived from the
  MACH microkernel and extended with a UNIX-like syscall API. Because the
  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.

:Linux process containers for supporting Genode`s resource trading:

  Even though the Linux version of Genode is primarily meant as a development
  platform, there exist interesting opportunities to explore when combining
  Genode with Linux, in particular Linux' process containers.
  Linux process containers provide a mechanism to partition physical resources,
  foremost CPU time, between Linux processes. This raises the interesting
  question of whether this mechanism could be used for a proper implementation
  of Genode's resource trading on Linux.
  [http://lwn.net/Articles/236038/ - Process containers introduction...]


Optimizations
#############

:Low-latency audio streaming:

  Genode comes with an audio streaming interface called 'Audio_out' session.
  It is based on a shared-memory packet stream accompanied with asynchronous
  data-flow signals. For real-time audio processing involving chains of Genode
  components, streams of audio data must be carried at low latency, imposing
  constraints to buffer sizes and the modes of operation of the audio mixer and
  audio drivers. The goal of this project is to create a holistic design of the
  whole chain of audio processing, taking thread-scheduling into account. A
  particular challenge is the mixed output of real-time (small buffer, low
  latency) and non-real-time (larger buffer to compensate jitter, higher
  latency) audio sources.

:De-privileging the VESA graphics driver:

  The VESA graphics driver executes the graphics initialization code provided
  by the graphics card via an x86 emulator. To initialize a graphics mode, this
  code needs to access device hardware. Currently, we permit access to all
  device registers requested by the graphics-card's code. These devices include
  the system timer, the PCI configuration registers, and the interrupt
  controller, which are critical for the proper operating of the kernel. The
  goal of this work is to restrict the permissions of the VESA driver to a
  minimum by virtualizing all devices but the actual graphics card.