[cap-talk] Can We Make Operating Systems Reliable and Secure?

[Jed at Webstart]

At 10:58 AM 5/8/2006, Ian G wrote:
>May be of interest...
>
>=================
>http://www.osnews.com/story.php?news_id=14532
>
>The micro vs. monolithic kernel debate is now very much alive.
>Not too long ago, I wrote an article on the merits of microkernels,
>while a week later we featured a retort. Now, the greatest
>proponent of the microkernel steps in-- yes, Andy Tanenbaum
>writes: "Microkernels - long discarded as unacceptable because
>of their lower performance compared with monolithic kernels -
>might be making a comeback in operating systems due to their
>potentially higher reliability, which many researchers now
>regard as more important than performance." Now, we only need
>Torvalds to chime in, and it's 1992 all over again.

I happened to be thinking a bit about this area recently, so I'll
contribute some of that thought.  In particular with regard to:

"...major drawback of a muK: overhead. Because all of those
processes are separated, and need to communicate with one
another over greater distances, a muK will inevitably be slower,
performance-wise, than a comparably featured monolithic kernel."

We faced this performance issue with NLTSS in about 1985.  In
particular our hardware (Cray-1, Cray-XMP, and Cray-YMP) usually
provided a very low latency (small # of microseconds) "Solid State
Disk".  We found that with our micro kernel architecture, the number
of expensive domain exchanges from user process to the micro kernel,
to the file server, to the SSD driver, back to the file server, back to the
micro kernel and back to the user process was large enough that
it was the dominant factor in the latency of I/O operations to SSD.

Our answer to this latency/performance problem was to move the
threads for the file server service routines from a separate file
server process into a "kernel process".  In doing so we directly
traded off performance vs. integrity/protection without affecting the
overall micro kernel design of the system.  Since the service routines
in the file server were already in the form of threads, this really amounted
to 'just' moving those threads from the file server process (which became
empty and was removed) to this kernel process.  At that point a failure
of the file server could take down the whole system, but in practice
a failure of the file server would pretty much bring down the system
anyway.

User processes still communicated to the file server (whether their
local file server or one on a remote system) by messages,
but with the file server in the kernel quite a number of domain
exchanges were eliminated and the performance of the system
was significantly improved for local access.  There is a brief
discussion of this topic in:

http://en.wikipedia.org/wiki/Nltss#Implementation_and_design_issues

If the debate about micro kernels vs. monolithic kernels heats up
again I just thought this means of trading off performance vs.
protection ("processes in the kernel") should be on the table.

I'm an advocate for micro kernel architectures.  I believe they offer
more effective means for making effective tradeoffs between
performance and reliability than do monolithic kernels.

Of course I believe that having a communicable authority token
(a capability) is an indispensable aspect of any micro kernel
architecture.  I also believe that "password capabilities" as data
are an inadequate capability design - though infinitely better than
no capability architecture at all.

--Jed http://www.webstart.com/jed/