Subject: Re: compartmentalization of kernel memory
To: NetBSD Kernel Technical Discussion List <email@example.com>
From: Kamal R Prasad <firstname.lastname@example.org>
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
> 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
Greg A. Woods
+1 416 218-0098; <email@example.com>;
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird