Virtual Machines an evolution of Virtual Memory?

[FWMiller]

Just thinking out loud. And please tell me if this topic has already been discussed.

I'm wondering if we can't look at the implementation of Virtual Machines, the x86 VMM instructions for example, as an evolution of Virtual Memory as a feature.

So, what I mean is this, lets say you took a stock UNIX like kernel design and simply replaced Virtual Memory with Virtual Machine? The VMM contains all the functions that a standard UNIX like kernel contains, device drivers, file systems, networking protocol stacks, etc. The VMM exports a "system call interface" and each VM is basically a process. It runs a single address space, multithreaded application, just like a UNIX like kernel would in a virtual address space.

Seems to me that this approach gets you potentially some more protection between applications at the User level but probably is more expensive since switching between VMs is likely more expensive than switching between virtual address spaces.

Any thoughts or discussion on such a kernel design?

Thanks,
FM

[speal]

What you're proposing is not unlike the MIT Exokernel design, which serves as a resource multiplexer. Wikipedia has a nice entry on this.

The virtual machine aspect of your proposal is an interesting one because much of this "multiplexing" can be done for you by hardware if you use hardware-supported virtual machines (ie. AMD-V). That said, I'm not sure what sorts of limitations there are on the number of hardware-supported virtual machines running concurrently.

What you may be getting at is a compartmentalized design that could be easier to maintain than a complex multitasking OS. If you can successfully implement a kernel that allocates each process a virtual machine, you can run a single-tasking (or extremely simple multitasking) OS inside each machine. I would be willing to bet that with some careful design, you'd be able to write a more maintainable, secure, and simple kernel by breaking it into the resource multiplexer and task-kernel.

[FWMiller]

I'm somewhat familiar (having read several papers) with exokernel. I was under the impression that their approach was to export a low level hardware interface to the application/virtual machine/guest os. In that sense, it looks a lot like what VMware is doing. This would differ from what I am proposing. In this approach, a standard UNIX like API, e.g. fork, open/close/read/write, socket, etc., would be exported as the lowest level API for each VM.

You're correct in that the applications would then basically just be regular applications as they run today on UNIX, using essentially the same libraries etc. built on top of the same kernel level system call API. The difference would be the use of the VMM hardware to enforce separation rather than just using virtual address spaces.

Such an approach allows you to port existing UNIX software, but presumably each application/process would be more isolated, i.e. better hardware enforcement of isolation.

FM

[JamesM]

I don't quite understand how you would export such an interface to a virtual machine. How would the VM call fork()/exec() etc? and more importantly why would it want to? A VM is just that, a Virtual Machine: It runs its own OS which provides syscalls itself.

I suppose you could create your own bios for said VM and expose an interface as realmode interrupt handlers, but again it begs the question "what exactly does a fork() mean in the context of a virtual machine"? A VM isn't a process, it can't be forked!

I'm somewhat confused. Perhaps you could explain more clearly?

[Combuster]

The main difference between a virtual machine and a kernel is that the second provides higher-level functions to its client while the first lets everything be figured out for themselves. An exokernel is about multiplexing hardware. It can use VM technology to this extent, but it will still need to allow processes to communicate with one another. Having something like an emulated NIC in a NAT-like environment defeats the speed advantages of allowing more direct communication channel between VM clients. Besides, it becomes very difficult to manage shared devices like storage space that way.

An exokernel in itself is not about hiding away the OS, it is about giving the program the most control over hardware that is safely allowed. A program will still want to be aware of that functionality being present so it can take advantage of it.

Using VMs to isolate programs isn't the worst of ideas. It allows the program to tweak any processor state to its advantage. The OS can still slip in hooks to enter the kernel (which is at that point the hypervisor) and do the tasks you would normally ask of it.
The question is wether the amount of extra effort weighs up to the advantages gained from it - in most cases I'd say no, but doing things like running a dos emulator would be able to put these things to good practice. Let's just hope that the timer bug is absent in whatever you try to run .

IMO true exokernel design would allow the user to choose wether to be run in a VM or not.

[Avarok]

Heh...

You could technically share memory between VM's. There's nothing stopping you except the overhead on sending the message to share.

[FWMiller]

Interesting discussion.

Regarding whether you would want to export a kernel level system call interface through the VMM API, this is really the question I'm exploring here. Every VMM I've seen focuses on exporting essentially a machine level API.

I don't think it would be difficult to actually implement it. You're analogy to BIOS is apt. It might be as simple as defining some sort of interrupt mechanism.

I think what I'm getting at here is to look at the VM mechanism a little differently that it has been to date. Rather than looking at it as a way to virtualize hardware directly, my thought is to look at is as essentially a beefed up protection mechanism. Virtual memory provides hardware enforcement of memory accesses but the operating system kernel has to define and enforce in software, access to other system resources. The new VM hardware present in the Intel and AMD chips take this protection to a new level. By virtualizing essentially everything in the system, they have essentially expanded the ability of hardware to enforce access to every system resource.

So, if you take a step back and consider using the VM hardware as a way to do hardware enforced protection of everything and then design a single operating system kernel around that, it probably changes the way you architect the overall system and the kernel itself. Thats what I'm trying to think through here.

Thanks,
FM

[DeletedAccount]

In your design i think the kernel does the switching between
virtual machines right ..? Your design seems to enforce more
security than the exokernel ... But i think it's better have
virtual machines that provide a simpler interface ...
virtual machine that implements unix system calls as
instructions is much complex to design and implement ...
Also the later design offer less flexibility .. This is
precisely the reason why machines are built with
simple instruction sets ..

Check out : JX operating systems ... I have tried it and
the performace is quite okay

[earlz]

ok...I'm almost for sure they don't mean making system calls into instructions...that just sounds stupid(wait...ahh yes...stupid)

so this is what it's like to wake up at 4am..

[FWMiller]

The Intel and AMD virtual machine constructs do not export anything new besides the same machine leve instructures that any x86 machine does. To export a UNIX level API through this interface, you would essentially use these instructions appropriately to implement what looks like a system call interface.

For example, if you look at the following book:

Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3B: Systems Programming Guide Part2

Chapter 21 of this book describes what are referred to as "VM Exits." Sections 21.1 and 21.2 list the events that can occur when a VM is running "in guest mode" that case a trap to the VMM. There are any number of machine instruction executions that can cause such an event, but there is an explicit instruction called. For example, each VM could be configured to trap the the VMM on an interrupt. An application would then configure a data block with parameters, signal an interrupt which would invoke the VMM. This mechanism would not differ greatly from how BIOS is invoked.

The data block passed during the interrupt processing could spec the system call number and any parameters required. Voila, a system call interface mechanism.

Thoughts?
FM

[Avarok]

I think we agree in good ways about the Pacifica Intel-VT technology's implications. It's viable as an exokernel enabling technology.

I am mostly curious about how a program asks for things. I suppose the best way is to simply define as data what needs to be loaded, rather than using calls within the program.

Then the [invoking application] can invoke whatever libraries it trusts to make available the libraries the application trusts. Applications can assume they have exclusive access, and OS's can multiplex ports without caring which port even? (perhaps naive of me)

Provided that, it should be possible for the application to never speak to the OS; making it as secure as the platform could possibly allow.

[quartsize]

It's viable as an exokernel enabling technology.
...
Provided that, it should be possible for the application to never speak to the OS; making it as secure as the platform could possibly allow.

I do not think that virtualization is useful for implementing exokernels. Part of the advantage to exokernel systems is that the applications running on them are given few illusions. Virtualization allows you to run unmodified operating systems because it tricks the operating system into believing it is alone on the machine. This is similar to how a traditional operating system provides the illusion of a process being alone in memory and having uninterrupted processor time.

Applications on exokernel systems are able to take advantage of knowing when they can have processor time, how much memory is available, disk space, network bandwidth, etc. So I do not believe that virtualization, which hides this information, would be useful for an exokernel.

[Avarok]

Interesting... I agree that few illusions is good. That's exactly why I disagree with you and think that virtualization is perfect for exokernel design.

How you interact with a port on raw hardware is exactly how you do in a Virtual Machine. It doesn't get more transparent. The OS just multiplexes securely. This is significantly better than a VMM where each application really does need to use an OS provided API, 'cause the OS can't secure it otherwise. It's the API that chains us, that binds us and drags us into hideous masks upon hideous masks.

/me thinks philosophically.

[FWMiller]

I think that the Virtual Machine Monitor (VMM) is essentially the same as an exokernel as I understand them.

I don't mean to be rude, but I was hoping for comments on my proposed design of a kernel within the VMM space that exports a traditional kernel API rather than this discussion of what an exokernel is. Could we stay on topic please?

Thanks,
FM

[Combuster]

A virtual machine is NOT an exokernel. An exokernel abstracts the hardware while a virtual machine emulates it. The key difference is that the one hides the implementation details while the other exposes it.

In fact the concepts of a VMM and a kernel are orthogonal - you can have a VMM that isn't a kernel but a piece of regular software (like VMWare), you can have a kernel that can not run programs in a VM (many oses, especially the older ones), or you can have a kernel that uses VM technology to isolate its processes, and is therefore both.

I agree that few illusions is good. That's exactly why I disagree with you and think that virtualization is perfect for exokernel design.

You just said that an illusion isn't an illusion. A program acessing what it thinks are real ports will not know that the system is shared among many processes. You are creating the illusion that the process is alone. A true exokernel would allow the process to be aware of the other processes and make decisions based on that.
Consider how you are going to distribute system memory to its VMs and make them aware of that choice, keep it fair, and not waste anything.