Hybrid (micro)kernels

rwessel (robertwessel@yahoo.com) on 5/16/06 wrote:
---------------------------
>Rob Thorpe (robert.thorpe@antenova.com) on 5/16/06 wrote:
>---------------------------
>>You could do something like this:
>>
>>* Have a kernel containing the most essential things, scheduler, start-up etc.
>>* Have a small compiler hooked to the kernel capable of compiling from some simple
>>intermediate language into machine code. (Maybe it need not be in the kernel)
>>* Have less core things, like device drivers, and file systems held in intermediate code.
>>
>>When a sub-system is needed it is compiled. To compile it there is a function something like
>>
>>compiler (code_block, allowable_mem_accesses, allowable_io, etc);
>>
>>I.e. the compiler takes as argument what memory and IO the code is permitted to
>>access. It then compiles the code with those limits. Anything it statically verifies
>>are inside the limits is compiled directly, for anything it can't it inserts checks.
>>
>>The compilation could be done for device drivers etc when their memory spaces are
>>known. Which may be boot time or build time or some other time later.
>>
>>
>>This seems a complex way to go about the problem, the compiler would have to be
>>good. But there again most kernels are fairly complex anyway.
>
>
>I can see it now... Device drivers written in Java... ;-)
>
>But seriously, that seems like overkill. Any trustworthy compiler for a type-safe
>language will do the trick. They just have to accept (well typed) pointers to the
>objects they reference. And I/O ports are mostly ignorable - since essentially
>nothing that's performance critical uses them, you can provide access though an
>(checked) API (at least on platforms that actually support I/O port instructions
>- implementations that fake PCI ports with memory mappings are obviously in the original scenario).

I don't think that could quite work.
Lets say a device has a region of memory it uses to communicate with the it's driver. The data in the region is to the language using it untyped, it must be cast into the correct types. e.g. The driver knows that at memory address 56a3fb21 is a struct something_t. This is why I was proposing some method for loosening checking, for a restricted range of memory.

There are two different thing to think about here though:-
* The correctness of types
* Whether the driver can steamroller other code

Even with perfectly checked and verified types it's still possible to address completely the wrong things, write to the wrong places etc.