Anti-virus, virtualization and security paradigm

This is a very interesting interview with Joanna Rutkowska, the author of a "Blue Pill" rootkit. She just confirmed an opinion I had for a long time: that AV programs are mostly useless (heck, she doesn't even run one on her WinXP 64-bit machine).

AV detection is an inherently undecidable problem; therefore it will always be possible to create an undetectable virus. Without needing a rootkit that puts the OS into a VM.

Her wish (quote):

"The solution that I would love to have would be based on integrity checking of all the system components, starting from filesystem (digitally signed files), through verifying that all code sections in memory haven't been modified (something I partly implemented in my SVV scanner) and finally checking all the possible "dynamic hooking places" in kernel data sections."

is not realistic (unless the scanner is in the hypervisor) because of the question: How does the scanner ensure its own integrity?

What I would like to see is a paradigm shift in the security industry. It should put more weight on prevention and damage containment rather than source code auditing and scanning of programs/memory. Both techniques have been in use for a very long time and they don't work very well.

My view is that the OS should use the virtualization technology to create extremely light-weight, isolated environments; in the extreme case 1 VM per running application (this requires some heavy engineering to be doable efficiently - eg. sharing of the core OS code between VM instances). Each VM would expose only those parts of OS functionality that is absolutely neccessary for the application to work. Information flow between VMs would be strictly under user control (thus, making the user once more the weakest link in the chain).

There lie some heavy research questions in my proposal:

1. Efficient memory utilization (it would be infeasible to completely copy all of the underlying OS into each VM). Hypervisor would have to be intimately tied to the "guest" OS.
   
2. Policies for information flow between VMs.
3. Efficient history saving (so that user can roll back to some previous VM state).
4. Interoperability with other VM products like Xen or VMware.

Regarding the last point, there is an interesting comment in the AMD64 Pacifica manual for the VMRUN instruction under "Instruction intercepts":
"Note: The current implementation requires that the VMRUN intercept always be set in the VMCB."
Is this a hint that, in the future, we might get HW support for recursive virtual machines?