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

[David Hopwood]

Jed at Webstart wrote:
> 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.

You would be wrong. As the article says:

# To make matters worse, typically, about 70 percent of the operating system
# consists of device drivers, which have error rates three to seven times
# higher than ordinary code, (3) so the bug counts cited above are probably
# gross underestimates.

where reference (3) is

  A. Chou, J. Yang, B. Chelf, S. Hallem, and D. Engler.
  An empirical study of operating system errors.
  In Proceedings of the 18th ACM Symposium on Operating Systems Principles,
  Oct. 2001. pp. 73-78.
  <http://citeseer.ist.psu.edu/chou01empirical.html>

Of course, 70 percent of the code run by any particular OS instance is not
in device drivers, since most of the supported devices are not present in a
given hardware setup. However, that just means that at least some drivers
aren't tested as consistently as the code that is common to all installations.

I would *guess*, considering the diversity of PC hardware, that the
distribution of drivers needed by a system is a "long tail distribution".
If this guess is correct, then most users will have some drivers that are
poorly tested.

> Regarding paravirtualization approach - of course new Pentium
> and AMD processors are now coming out that are fully virtualizable.

Well, more easily virtualizable. VT-x and Pacifica boxes still need quite
a substantial and complicated virtual machine monitor. Perhaps too complicated
to be secure, since the reliance set of a typical VMM is larger than that of
a typical microkernel presenting its "native" kernel interface.

> That means that this approach would not have to deal with modifications
> to the operating systems to run under the virtual machine monitor.

Right, although the distinction between virtualization and paravirtualization
is not sharp: most VMMs just try to provide a virtualization that works well
enough to run the most commonly used guest OSes, perhaps with minor changes to
their configuration or additional/replacement device drivers.

In support of Tanenbaum's point, Xen considered as an OS is less monolithic
than most (although it is not a true microkernel, and relies heavily on giving
the "dom0" domain full privileges to access the hardware). L4 can be used as a
VMM, and VMWare's ESX Server is sort-of a microkernel, IIUC.

> 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.

It isn't the support for standard buses and I/O interfaces (USB, PCI, DMA, etc.)
that take up the vast amount of device-related code in an OS; it's the
drivers for particular devices that are accessed via these standard interfaces.

> 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.

The only connection is the use of a trusted language implementation. For
the Burroughs machines this was an Algol implementation; for Singularity it
is an implementation of the MSIL intermediate language (with some extensions
relative to the .NET version, I think).

> 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've broken trusted language implementations (Java VMs) as well. But I don't
see why you say "forevermore"; a security bug in a language implementation
is not fundamentally different from a security bug in an operating system
using hardware memory protection, and is no less fixable.

It is true that most language implementations are more complicated than most
microkernels. That's why MSIL and JVM code are bad choices for this; they
are far too difficult to implement in a simple, verifiable way.

> I don't see any discussion of any sort of authority token that can
> be communicated to support POLA in Singularity.

It's a message passing system, and as far as I understand, the references in
MSIL are supposed to be unforgeable (from managed code; all non-managed code
must be fully trusted). I don't know how successfully it avoids ambient
authority traps. The two tech reports referenced at
<http://research.microsoft.com/os/singularity/> seem relevant, but I haven't
read them yet.

> 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.

There is a video where the main designers of Singularity basically say that they
don't expect to produce a successful consumer OS; that it's all just blue sky
research, from which various ideas may or may not be folded into Windows. I'll
try to find the URL for it.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>