Prerequisite mechanism that Genode expects from a new kernel

[Norman Feske]

Hello Althaf,

welcome to the mailing list! :-)

> Answers to my question does lie in /base-host directory and checking out
> already implemented base-xxx.However, before i dive into them if you 
> could explain the underlying mechanism that genode expect from a 
> new/fresh dedicated kernel meant to use genode it would help understand
> the /base-{host,linux,et al} better.

This is a very good question - but also a very tough one to answer in
general. The answer depends on the goal you are pursuing with the
kernel. For example, some of Genode's base platforms implement the
complete Genode API functionality-wise, but do not provide
kernel-protected capabilites that are needed to achieve the high
security as suggested by the Genode concept. But these platforms are
still fine for many use cases where security is not the primary concern.
The 'base-linux' platform is an extreme case because it actually does
not provide isolation between Genode's protection domains at all
(dataspaces are just files at '/tmp/' and threads communicate via
sockets w/o any access control). Still, this platform is extremely
valuable to us as development platform. The 'base-okl4' platform does
provide a certain degree of protection via L4 mechanisms but still lacks
a rigid way to constrain the inter-process communication. The only base
platforms fully supporting Genode's security model at the kernel level
are NOVA and Fiasco.OC.

Given that I do not know much about your actual goal, I am afraid that
my answer might be either too abstract to be useful or to much tied to a
particular kernel interface.

Let's first look at Genode from a high level by just examining its API.
To implement the API, the kernel has to provide mechanisms for
implementing the following functionality on top:

:The creation, destruction, and remote manipulation of protection
 domains:

  Strictly speaking, it is not entirely clear that protection domains
  are needed in all cases. I could imagine a version of Genode that
  executes all processes within one unprotected address space, i.e.,
  physical memory - similar to how uCLinux works. Of course, such
  a platform would not be able to provide protection and isolation
  between processes but for embedded applications that consist
  of trusted code only, this constuct might still be useful.

:Support for establishing shared memory between protection domains:

:A way to execute multiple threads in a protection domain, scheduled
 in a preemptive (non-cooperative) way:

  Again, this is not a definitive statement. A specialized platform
  might be able to function with merely cooperative multi-threading.
  In Genode, there is no inherent dependency on preemtive scheduling.
  However, applications may expect this semantics from Genode's 'Thread'
  API.

:Letting threads of different address spaces communicate in an
 RPC-like fashion:

  The mechanism for RPC-like communication could be synchronous IPC
  as provided by L4 kernels but it does not need to be. For example,
  some years ago, Genode's RPC API was ported to Xen, using shared
  memory and Xen's event channels only.

:Letting threads of different address space communicate via
 asynchnonous notifications:

  Those notifications do not need to carry payload. Raw signal
  semantics are fine.

:Lock-based thread synchronization:

  One important semantic detail is that once a thread blocks, the
  blocking must be cancelable by another thread. If you like, we
  can go into detail in a follow-up posting.

:Access to I/O resources such as interrupts and memory-mapped
 registers:

You see my struggle with giving definitive statements here? This is
because I believe that there is no single "right" way to go.

Let's also look from the other way, starting with concrete requirements.
When we wanted to run Genode on FPGA softcores, we decided to go for a
custom kernel design instead of adapting one of Genode's already
supported base platforms. Our goal was to find the simplest kernel
interface possible given that our use case does not require
capability-based security, and the hardware platform consists of a
single core with a software-loaded TLB. The resulting kernel interface
may serve you as inspiration. You can find it here:


http://genode.svn.sourceforge.net/viewvc/genode/trunk/base-mb/include/kernel/syscalls.h?revision=152&view=markup

> Like, threads, shared memory, sockets, paging, MMU support etc.It would 
> be excellent , if we have an article in [1] explaining porting to
> hypothetical kernel.

I would appreciate you providing us with some more details about the
goals you want to address with your custom kernel. E.g., Is it meant to
be as simple as possible? Which degree of security do you want to
achieve? Should your kernel scale to many cores? Which hardware
architectures do you have in mind?

Best regards
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