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...

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

Hi Althaf,

specifications, however i realised its an adaptive framework. I will give a notion of what i had expected, well i envisioned it to be one like DDEkit- or Secure Userspace Execution Enviroment kit ( SUEEkit) over 'any' mono/micro/hypervisor kernel, though it is correct, I conclude from your reply that there is no solid bottom layer specification?

the Base API can be regarded as a "bottom layer specification" (its implementation is typically less than 10KLOC) of the whole system but there is no fixed base-internal interface. This gives each platform maximum flexibility about how the API is implemented. Given the vast differences of the mechanisms used, this flexibility is needed. E.g., by comparing the ways processes are created and address spaces are managed on Linux and L4, you will see that the respective base code has almost nothing in common. On Linux, 'rm_session()->attach()' is implemented locally by the calling process using mmap. In contrast, on L4, the same API function is an RPC to core, which, in turn, manipulates the address space on demand (using L4's map/unmap) when a page fault occurs.

About my requirement, well i would like to adapt Genode for daily use (on the long run) over a stripped down linux, ie not related to current base-linux which only a dev / proof of concept platform than complying to genode policy. I actually wondered why genode port to linux was using sockets, than other secure linux mechanism like Shared memory and et al.Now i understood why. ;-).

Thanks for this very interesting insight. Is your idea in line with the topic "Microkernelizing Linux" described on our "Challenges" Wiki page?

http://genode.org/community/wiki/Challenges

Let me suggest two pointers that we stumbled upon when we brain-stormed this idea. First, we were pointed to Linux' "resource containers", which promise to allow the assignment of fine-grained resource constraints to individual processes. This looks like an interesting mechanism to support Genode's resource-trading concept. Secondly, we were made aware of the Capsicum project, which brings capability-based security to Linux.

http://www.cl.cam.ac.uk/research/security/capsicum/

This looks like it may fit for securing the IPC communication between Genode processes on Linux.

Best regards Norman