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

Jed at Webstart donnelley1 at webstart.com
Mon May 8 20:11:03 EDT 2006


At 03:22 PM 5/8/2006, David Hopwood wrote:
>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.
> > ...
>
>The actual article by Tanenbaum:
><http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl&>
>is interesting and well-written. Don't bother with the comments and
>other links at osnews.com; they're just a waste of time, with a
>superficiality to rival Slashdot.

That is an interesting article.  I'll make a few comments here.

It's interesting to me that so much focus is given to device drivers.
While device drivers are out of control of the writers of the operating
system, I would think that the amount of code in the device drivers
is relatively small compared to the other code in the system.

Regarding paravirtualization approach - of course new Pentium
and AMD processors are now coming out that are fully virtualizable.
That means that this approach would not have to deal with modifications
to the operating systems to run under the virtual machine monitor.

Regarding "multiserver operating systems", the idea has been around
for at least 27 years (since we implemented such a system starting
in 1979, and I don't think it was new at that time).

In this section I think I begin to understand a bit more what Tannenbaum
means by "device driver".  He says that these "device drivers" "cannot
execute privileged instructions or read or write the computer's I/O ports;
they must make kernel calls to obtain these services".  It is exactly the
code that can directly read/write the computer's I/O ports (often by
executing privileged instructions) that I have heard previously referred to as
"device driver" code.  It seems that what Tannenbaum (et. al.) is referring
to as a "device driver" is some higher level software.

One question to ask in this scenario is whether kernel software can
be written so as to provide the needed services to the various "device
driver" processes in a way that is device independent - hopefully while
still providing as much protection as possible from failures of the
device drivers.  Perhaps this question is answered in the Minix 3
implementation.

I read through the concepts described for "Singularity" from Microsoft
Research.  I guess I'll have to take a closer look at that project:

http://research.microsoft.com/os/singularity/

I think it can have only the most tenuous connection to the approach
used on the Burroughs B5500-B7700 series of computers.  Those were
tagged architectures that might be called descriptor based machines.
They depended on language protection even for user applications.  This
approach was very unwise as any user application that was able to
exploit a bug in a compiler would forevermore constitute a hole in the
security/protection perimeter of the system.  I know a bit about this because
I owned such a hole at one time.

I don't see any discussion of any sort of authority token that can
be communicated to support POLA in Singularity.  Perhaps the mechanism
for sharing heap "object"s is the basis for such a facility?

At least Minix 3 is available as open source software.  I don't understand
how Microsoft Research expects to be able to compete with closed source
software like Singularity.  It will be interesting to see what comes out of all
these various efforts to improve the reliability of computer systems.

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




More information about the cap-talk mailing list