Virtualization security, some thoughts about it

I was reading the post from Hoff where he writes about virtualization and the DMZ, based on a white paper from VMware. I've been reading Hoff's posts (and others with whom he discusses the subject) about virtualization and I thought it would be interesting to also right a little about it.There is a lot of research results being published regarding VM security. Some of those try to demonstrate security issues, like malicious hypervisors, systems trying to escape its VM and trying to reach other VMs or even the hypervisor, some are proposing ways to avoid and detect those threats, and so on. I firmly believe that we can reach a very high level of security to protect the hypervisor and its role from threats coming from the VMs. That's because of the difference of "security layers". There are lots of cases of success of code running in a higher privilege layer controlling code running under it, like VMS, Java VM and others. People are working with VM technology on the mainframes for years and it they were (the problem with the mainframe world is it lacks its own ShmooCon, DefCon, BlackHat, etc) able to reach a decent level of security on that.There are some features that are being virtualized that will demand us a little more care to ensure a good security level, like the network devices roles. I also believe that it's not that far either. We were able to produce fairly decent code to run on switches and routers, if we bring the same code to the VM world (would Cisco be bold enough to offer something like "VMIOS", to run several instances of its boxes on a single big box?) we can do that there too.The big issue that I think it will remain is the VM and Hypervisor environment security, I mean, the environment where that highest level VM software is running. Based on my understanding (and I think it's almost common sense), whoever controls the hypervisor rules the VM world. The VM servers are being assembled like a common server, but the VM software should be quite more protected than a common application. Can you imagine running your "Virtual DMZ" over a Windows 2000 server, knowing all the other software that is also running on that and can't be disabled or uninstalled? The attack surface of the server running the VMs needs to be VERY small. On mainframes the top layer (where the LPARs are running over) can usually be accessed only from a local console. No network access, terminal. Nothing. I know that on the distributed computing world this can't be a huge headache to manage, but we don't need to go that far. I believe that the Server Core option for Windows 2008 is a good example of where to place a VM environment over, or something like a YALD (Yet Another Linux Distribution) specially prepared from scratch to be a VM server. The kernel, the VM software and nothing else. Maybe SSH for (console) remote management, but that's all. Can anyone find a reason to have Gnome or KDE running on a VM Server? I can't.Maybe I'm being a little naive when analyzing the VM problem this way. But I'm looking at the "VM" experiences from the past and I can't see challenges that go beyond that. If you start thinking about very different communication between VMs besides common vanilla networking (like sharing memory areas), maybe it's time to think why you are trying to do that instead of placing the apps from those VMs under the same OS. And for securing basic vanilla networking on VMs, we are almost getting there.