Pages: p. 5
Thanks for a fine article in last issue's IEEE S&P, Iván Arce's "Ghost in the Virtual Machine" (July/August, pp. 68–71).
It's good to see the work of Popek and Goldberg re-emphasized. Although para-virtualization schemes like VMWare's are useful application-management tools, it's important to point out that they might not solve security problems. As one of those "early days" guys who worked on CTSS and Multics, and managed a CP/CMS system, I hope that others will learn the lessons we did, too.
When they first appeared in the '60s, virtual machines were appealing because they promised separation of concerns: the CP [control program] would do the machine multiplexing, the guest operating systems could be simplified, and—crucially—the machine specification for the virtual machine was clean and rigorous. A virtual 360 has relatively few instructions, compared to the 80x86. Olin Sibert and his colleagues' paper, "An Analysis of the Intel 80x86 Security Architecture and Implementations" goes into the details. Since 1996, Intel has introduced new "super VM" instructions and registers, but I can't find a paper with a definitive analysis of the security of these new modes. They were supposed to cure the virtualization weaknesses of previous processors. But history shows that the true enemies of OS security are features added to the basic system without enough security consideration. Consider Windows NT, which was originally proposed with good security design.
Every time-sharing system provides some kind of virtual machine. CP's brilliance was to provide a VM that looked exactly like a 360 in its principles of operation. Except not really, of course: self-modifying channel command word (CCW) chains were one difference, CPRequest was another, and each difference was exploited. CTSS provided a VM that was just like a 7094, except that instead of causing an error, one instruction invoked one of 100 or so supervisor functions. The Multics VM was similarly more powerful than any bare machine.
Regarding the confinement problem, the key observation is that every shared resource is a channel. VM monitors that share resources create channels between compartments. The only way to prevent communication over these channels is to use static allocation—that is, to eliminate dynamic sharing. The paging channel described in www.multicians.org/timing-chn.html was one such, but the much higher bandwidth provided by the sharing of various on-chip caches, and the subtler channels resulting from the sharing of power and heat in modern processors, are going to be difficult to close.
— Tom Van Vleck
Thanks for Iván Arce's Attack Trends article highlighting possible attacks in a virtual machine. Nevertheless, it would be better if some solutions or strategies for securing VMs were suggested.
In addition, you should mention the Java Runtime Environment, which is basically a VM with additional features, such as support vector machines to secure VMs. Although only a set of simple criteria was applied, Java SDK lets developers modify and add user criteria. It seems to be the most convenient way to achieve security for consumer platforms.
— Horace Cheng
Thanks to you both for your feedback. The reference to the paper from Sibert et al. is spot on. I read it some time ago, but when I wrote the article in question, I decided, in the interest of reducing the number of references, to put the emphasis on what Scott Robin and Cynthia Irvine wrote as a follow-up five years later.
Contrary to popular belief, microprocessors are no longer "just hardware" (they haven't been for many years), and they expose a wide and feature-rich attack surface that's as prone to implementation bugs as any other man-made artifact. This is where the virtualization dream meets the reality of potentially flawed implementations, with the availability of cheap, powerful, feature-rich hardware (and the software that drives it), the degree of complexity that a virtual machine monitor (VMM) must deal with increases exponentially, and that's bad news for security. The confinement problem remains, for almost all practical cases, an unresolved security issue as well.
— Iván Arce