New challenges ahead
fithis2001 at ...9...
Thu Mar 24 16:01:07 CET 2011
The IOKit and XNU are very interesting for me along with the IOMMU
support. If IO/Kit is ported, Xorg/IOKit could be reused.
On 3/24/2011 4:00 PM, Norman Feske wrote:
> with each new Genode release, we find ourself inspired to reach out for
> a growing number of use cases of the framework. There is a dedicated
> Wiki page for documenting those ideas:
> However, this Wiki page received not much love during the last year.
> Now, after having released the version 11.02, we took the chance to
> reiterate over the many ideas that popped up recently. We are actually
> pretty excited about all the prospects that have become feasible now.
> So if you are curious about what kinds of projects we have in mind in
> the mid term, have fun browsing through the project proposals. If one of
> these topics catches your interest, we'd be happy about you joining in
> with the development. Also, if you have additional ideas, please do not
> hesitate to tell us more.
> Here are the challenges that we just added, sorted by category:
> Chrome web browser
> The Chrome web browser promises to address the most pressing security
> concerns of web application by isolation measures, in particular the
> sandboxing of plugins and the confinement of individual web
> applications. As we demonstrated with the Genode Live CD 10.11, Genode
> facilitates a more natural way to pursue such techniques compared with
> current commodity operating systems. Furthermore, the use of Genode as
> base platform for Chrome would strengthen the web-browser security by
> dwarfing its trusted computing base by two orders of magnitude
> compared to the use of Linux as base 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
> With 'Input' and 'Framebuffer', Genode provides two low-level inter-
> faces 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.
> 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
> Interactive sound switchbox based on the 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 show case
> 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.
> 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 Qt4
> 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
> 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 Qt4 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.
> Application frameworks
> Running the Meego application stack on Genode using Qt4
> With Genode 11.02, Qt4 4.7.1 has become available. The most prominent
> feature of this version is the new QML language to design GUIs using
> a declarative language. This technique is targeted specifically to
> mobile applications and 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 Qt4 bindings
> With the Python interpreter and the port of the Qt4 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 Qt4 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 Qt4, 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.
> 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
> SATA block driver
> Genode already features a session interface for accessing block
> devices. Currently, there exist two implementations of this interface,
> which are the ATAPI block driver for accessing CDROMs and a loopback
> block driver. The goal of this project is a working SATA driver that
> enables the persistent storage of data on disk. It is a prerequisite
> for enabling the use of real file systems with Genode. We regard our
> ATAPI driver as a suitable starting point for such an undertaking.
> Genode 10.08 introduced Gallium3D including the GPU driver for Intel
> GMA CPUs. With this initial version, we demonstrated that the powerful
> software stack for running hardware-accelerated 3D applications can be
> deployed on Genode. At the same time, it motivates us to reach out for
> even more ambitious goals:
> First, the current approach executes the GPU driver alongside the
> complete 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
> interrupt-based synchronization, namely vblank handling. This requires
> an 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
> IOMMU support on the NOVA Hypervisor
> The NOVA hypervisor is the first open-source microkernel with thorough
> support for IOMMUs, which principally enables the use of untrusted
> device drivers alongside sensitive software on one machine. Without an
> IOMMU, each device driver for a device that operates with DMA, is able
> to indirectly access the whole physical memory through programming the
> device. With IOMMU, the physical memory addressable by DMA operations
> can be restrained per device. The goal of this challenge is to enhance
> Genode with I/O protection when running on the NOVA kernel. This would
> clear the way towards reusing complex untrusted device drivers running
> in dedicated device-driver OS instances.
> 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, Qt4, 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 "Cloning L4Linux" of
> Sebastian Sumpf
> 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.
> [http://halvm.org - HalVM] is an operating-system runtime that allows
> for implementing low-level OS components in Haskell. Currently, HalVM
> uses Xen as underlying kernel. The goal of this project is running
> HalVM directly on Genode, which would enable the adoption of this
> approach by the L4 community.
> 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
> 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
> Terminal emulation for Noux
> Noux is an emulation environment for executing command-line-based GNU
> applications on Genode. It was introduced with Genode 11.02. With the
> current state, Noux is able to run several GNU coreutils without
> modification, but it supports non-interactive applications only. The
> goal of this work is the creation of a Nitpicker GUI client or
> framebuffer client implementing a terminal emulator to be connected
> with the stdio channels of Noux. This would enable us to go forward
> with porting interactive GNU applications, in particular a shell, to
> 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 this mobile OS in high-assurance
> Vancouver VMM for Genode on the NOVA hypervisor
> Vancouver is the user-level virtual-machine monitor accompanying the
> NOVA hypervisor. It combines a VT-based CPU virtualization with a rich
> set of device models to run unmodified guest operating systems at
> near-native performance. Since NOVA is a supported base platform of
> Genode, running Vancouver in the dynamic Genode environment has become
> feasible. By running Vancouver on Genode instead of NOVA's original
> static userland would open up new use cases where the combination of
> faithful virtualization with dynamic applications is desired.
> 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++.
> Multi-processor support on different base platforms
> Several of Genode's supported base platforms come with multi-processor
> support, i.e., Linux, NOVA, L4ka::Pistachio, Codezero, and Fiasco.OC.
> Each of these kernels follows a different approach for utilizing
> multiple CPUs. For example, Linux and Codezero manage the association
> of threads with CPUs largely transparent for user-level programs. In
> contrast, NOVA makes the use of multiple CPUs explicit and constraints
> the modes of IPC interaction of threads running on different CPUs.
> Furthermore, kernels differ with regard 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
> 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 Genode FPGA Graphics SoC platform
> With Genode 11.02, we introduced the first version of native support
> for the MicroBlaze softcore CPU. With this foundation laid, we can
> proceed with bringing GUI-based interactive Genode applications to
> FPGA-based SoC platforms. As target SoC design, we aspire to use the
> open-source IP cores provided by the Genode FPGA Graphics Project:
> Support for the HelenOS/Spark kernel
> [http://www.helenos.org - HelenOS] is a microkernel-based multi-server
> OS developed at the university of Prague. It is based on the Spark
> microkernel, which runs on a wide variety of CPU architectures
> including Sparc, MIPS, and PowerPC. This broad platform support makes
> Spark an interesting kernel to look at alone. But a further motivation
> is the fact that Spark 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 Spark'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 seL4 kernel
> The seL4 kernel developed by NICTA and OK-Labs is the first formally
> verified microkernel. It runs on the x86 and ARM architectures and
> supports the execution of a paravirtualized version of Linux on top.
> Even though seL4 is proprietary technology, a free binary release and
> the specification of the kernel API has been published early 2011.
> Being a capability-based kernel, seL4 is in the line of the current-
> generation L4 kernels alongside NOVA and Fiasco.OC. Genode already
> supports the latter two kernel, which hints at the feasibility to
> support seL4 as well. Currently, the seL4 kernel comes with a rather
> static user land, which is far from utilizing the full potential of
> the kernel with regard to dynamic resource management. By adapting
> Genode to seL4, a rich dynamic application workload would become
> available to this kernel, which could potentially spawn interest in
> extending the formal verification efforts at NICTA to the Genode
> system executing dynamic real-world applications.
> Support for the Barrelfish kernel
> [http://www.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)
> 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.
> Automated testing on the Codezero kernel
> The Genode release 11.02 introduced an automated testing framework for
> all base platforms except for Codezero. Codezero was omitted because
> its build and configuration system requires user interaction. The goal
> of this project is to improve the Codezero configuration and build
> system to interface easier with Genode and to automate the build-and-
> integration procedure. This way, Codezero would become a base platform
> subject to many regular tests as performed with the other platforms.
> 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.
More information about the users