First, for those of you who may be confused by the "VM" vs. "OS" distinction, I believe that this is coming out of my dissertation and some later writings. The "VM" in question corresponds to the EROS kernel. The "OS" is the layer of services above that.
Eyal writes:
> As I understood, EROS operates on the principle of least
> privilage, and small trusted code bases when possible,
> but a Virtual Machine under the OS seems to be contradicting
> this.
> ...
> The OS, could be on the lowest-level, having a VM 'formed'
> of user-level applications, with capabilities to access
> hardware (drivers). That would be more consistent with the
> rest of the design, and even require less transitions
> between CPU ring levels (Jumps to kernel-level code)
There are a lot of things that impact this. You are definitely thinking in a useful direction. That said, let me try to tease apart some of the things that you have mixed together.
The first is some confusion about protection vs. security. The problem, in a nutshell, is that many pieces of hardware include DMA controllers that can alter physical memory. As a result, drivers for this hardware have authority to change physical memory. This effectively gives them total authority over the machine. There is no general way for the operating system to detect abuse of such mechanisms. Given this, there are good reasons of engineering to separate drivers from the kernel, but no additional security from doing so on most hardware.
It is possible, with careful hardware design, to build a system in which drivers do not need access to physical memory. KeyKOS, for example, had a single in-kernel driver for channel programs that allowed an arbitrary driver to run a program on a channel it controlled (via a device capability). Unless the hardware cooperates, however, this is not possible in general.
Removing the drivers actually requires *more* kernel transitions, not less. The difficulty is that you must go app->kernel->driver to invoke the driver. The driver must then go driver->kernel->driver to obtain physical address translation(s). Finally, the driver must go driver->kernel->app to return to the app. Note that data must be copied between the app and the driver, while the kernel can often use it in-place. Once again, there are designs to avoid much of the copying cost. The IOlite architecture could be adapted. Doing so raises a number of challenging resource allocation difficulties, as it is fairly easy to run out of I/O buffers unless storage allocation is carefully managed.
There are still many reasons to remove drivers from the kernel. Norm Hardy and I have talked about a number of designs for doing so, but have yet to find one that we are entirely happy with.
> A capability to hardware could be implemented a bit
> differently - using the I/O bitmap, and IOPL as the
> machnism to 'implement' the capability.
This would work on the x86, and it's one of the designs that I have looked at. The main problem is that it would *not* work on other systems, and it's strongly desired to have a common driver framework -- more and more so as things like PCMCIA, PCI, and USB come to be used across machines with different CPU and mainboard architectures.
> I would be interested in knowing why EROS chose to
> have a large trusted-code base containing hardware-access
> drivers under the OS.
The short answer is that because of the physical DMA issue, rearranging the code to remove the drivers doesn't really reduce the amount of code that needs to be trusted. There are many advantages to reusing existing drivers (contingent on inspection). Therefore, EROS doesn't export the drivers.
Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595