GSoc-2017: Platforms - Microkernelizing Linux, help needed

[Norman Feske]

Hello Sky Liu,

thank you for your interest in Genode!

> I'm a college student majoring Information Security in HUST, and I'm
> interested in genode's GSoC project on microkernelizaing the Linux
> kernel. I've been quite interested in microkernel OSs and
> virtualization, with limited experiences working on xen and the linux
> kernel. and have been in the MINIX community for a short time, so I was
> attracted by this challenge at the first sight.
> 
> However, I'm still new to the genode project. So I'll appreciate it if I
> could get from you some suggestions on where to get started. :)

The best way to start exploring Genode is the "Genode Foundations" book,
which you can download here:

  http://genode.org/documentation/genode-foundations-16-05.pdf

I recommend you to at follow the getting-started section, and skim over
the Chapter 3 (Architecture) and Section 4.7 (Component compositions) to
get a tangible feeling for Genode.

To practically tackle the "microkernelization of Linux", there are
actually two approaches. (1) The first approach is to enable Genode to
access devices of the Linux system you are working on. This is
convenient, but it bears the risk that a device driver (running in a
Genode component) may interfere with the Linux kernel, crashing the
system. The other approach (2) is booting a custom-made Linux system +
Genode's core as init process in Qemu. The latter approach would be
equivalent to how we work with the various microkernels.

Depending on your interests, you may quickly dive in into the actual
Genode code (1) or work on a custom run environment for Linux-based
Genode system (2) first.

Regarding the actual topic, the overall challenge is allowing Genode's
device drivers access to the hardware that is normally accessed by the
Linux kernel only. From Linux' point of view, Genode appears as a
user-level device driver. So one piece of the puzzle is to gain a good
understanding of Linux' user-level device-driver support. From Genode's
perspective, device hardware is accessed through the IO_MEM, IO_PORT,
and IRQ services of Genode's core component. So in principle, the topic
comes down to implementing these services for the 'base-linux' version
of core by using Linux' interfaces for user-level device drivers.

There are several stages:

1. By implementing the IO_PORT service, Genode components can interact
   with simple port-I/O-devices such as the PIT timer. The
   implementation should by straight-forward: When running core at
   I/O privilege level (IOPL) 3, core can execute the regular
   'inb', 'outb', etc. instructions. A simple test component could
   request a Genode IO_PORT session for, let's say, the PIT, program
   the PIT as a running counter, and repeatedly read the current
   counter value.

2. Non-trivial devices need access to memory-mapped I/O registers.
   Core's IO_MEM service makes such registers available to its
   clients as a dataspace (the concept is explained in the book).
   On Linux, dataspaces are represented as memory-mapped files, passed
   from core to the driver component by passing a file descriptor, and
   attached to the driver's address space via 'mmap'. Consequently,
   the problem comes down to core obtaining a file descriptor for
   a given physical address region. Here the challenge is to find
   a suitable Linux kernel mechanism that hands out portions of
   physical memory as a file descriptor.

   With the principle support for memory-mapped I/O and port I/O
   in place, it should be possible to run the VESA framebuffer driver.

3. Most drivers use device interrupts. To use those drivers, core's
   IRQ service needs to be implemented. Again, this calls for an
   investigation of Linux' user-level device driver support.

4. Direct memory access. Many drivers use DMA to let the device
   write directly into memory. For this to work, the driver must
   supply the targeted memory address to the device. On systems
   without IOMMU, this is the physical bus address. In order to
   use DMA on Genode/Linux, DMA buffers need to be allocated as
   contiguous physical memory and their physical addresses must
   become known to the user-level driver component. In systems with
   IOMMU, the device-physical addresses a virtualized. So there is
   more freedom. But the details ultimately depends on the Linux
   handling of IOMMUs.

5. In Genode, PCI devices are managed by the so-called platform
   driver. When a regular device driver needs access to a certain
   device, it does not use core's IO_MEM, IO_PORT, and IRQ services
   directly but it requests a platform session. A platform session is
   like a virtual bus where one or multiple devices are present,
   depending on the platform driver's policy. The platform session
   makes the device resources of those devices available to the
   client (the device driver). Under the hood, the platform driver
   opens IO_MEM/IO_PORT/IRQ sessions at core.

   In order to use Genode's existing arsenal of device drivers on
   Linux, we need either a platform-driver version specifically adapted
   for Linux (when re-using the Linux PCI driver), or investigate a way
   to use our regular platform driver (including the PCI driver)
   directly (this would be pretty cool!).

I hope that the level of detail does not frighten you. We certainly
don't expect you to complete all these stages. E.g., if completing stage
1 to 3, there would already be demonstratable results. Stage 4 certainly
requires an investigation into the ways about the interplay of the IOMMU
handling of the kernel with user-level device drivers. Stage 5 also has
a atrong design aspect to it.

It goes without saying that we won't leave you on your own. :-)

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