Subject: Re: compartmentalization of kernel memory
To: NetBSD Kernel Technical Discussion List <tech-kern@netbsd.org>
From: Kamal R Prasad <kamalrpr@in.ibm.com>
List: tech-kern
Date: 05/09/2003 06:11:14
[ On Thursday, May 8, 2003 at 06:36:02 (+0100), Kamal R Prasad wrote: ]
> Subject: Re: compartmentalization of kernel memory
>
> we can create bounds on the addresses that a particular module inside the
> kernel is allowed to access.

> Sounds like what you want to do, if you want to keep this as machine
> independent as possible, is compile and run your kernels with some sort
> of kernel-compatible "safe-C" runtime (i.e. one that's usable in a
> standalone bare-hardware environment) which does range and bounds checks
> everwhere on pointers (i.e. not just on array index pointers).

the runtime overhead is going to be really high (authors state it to be
130%-540%).


> Otherwise what you really want/need is to migrate to a micro-kernel
> where every "module", as you put it, really can be run in a separate MMU
> context so that all the benefits of user-land address space containment
> can be had for device drivers, filesystems, and such.  You should have a
> look at Darwin aka Apple MacOS X to see a production micro-kernel OS....

microkernels have overheads associated with them.
Bill Studemmund mentioned the problem of having s single MMU context in
unix -but I am not sure if it is going to inhibit one from placing bounds.
re:- placing drivers in userland, it is expensive in terms of context
switch time (as Bill pointed out). the only way I would like to do is by
making the least amount of changes both to the code and to the architecure
(and to the run-time performance).
I think placing bounds in (GP) registers will not affect run-time
performance.
regards
-kamal


                   Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;
<woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird
<woods@weird.com>