Analysis of the Intel Pentium's Ability ot Support a Secure Virtual
Machine Monitor

John Scott Robin, Cynthia Irvine

* Summary: The Intel Pentium is not suitable as a secure virtual machine
monitor.

* Main Points:
  
  - Paper makes the distinction between a type I VMM (running on bare
    hardware) and a type II VMM (running on a host operating system).  

  - "A highly secure type II VMM will require a highly secure host OS"

  - The Pentium makes virtualization difficult for several reasons:

    1) Machine status registers are readable and sometimes writeable!
       from user mode.  A secure VMM shouldn't allow a guest OS to
       even read a status register.  In particular, the guest OS
       shouldn't be able to tell that it's running in user mode.

    2) Certain instructions behave differently in user mode and
       privledged mode.  In at least one case (POPF), an instruction
       executed in user mode can fail silently (i.e., without raising
       an exception).  

  - An intesting discussion of some secure virtual machine monitors
    for the VAX and the VM/370.  Great references.

* Evaluation

The authors clearly write from a military security perspective, so
their assesment of the suitability of the Intel may be overly
pessimistic.  For example, it may be acceptable for a guest
OS to read a status register, as long as it doesn't act on that
information, i.e.:

assert (getStatus() == PRIVLEDGED);

... would clearly not work.  However, we could conceivably remove such
calls from the operating system, either by hand or with binary
rewriting.  Finding all such instances could be tricky, however.

Much more troublesome are the instructions that allow user code to
WRITE to status registers.  PUSHF and POPF allow the EFLAGS register
to be modified.  Even worse, if the request fails, it fails SILENTLY.
This is clearly unacceptable.

The authors do not discuss the problem of self-modifying code
directly.  This seems like another huge problem.

This paper suggests some desirdata for a virtualizable processor:

1) Machine status registers must be completly separate from
   general-purpose registers.
2) Any attempt to read or write a status register from user mode
   should be trapped. 
3) Instructions should either work correctly, or throw an exception.
   The outcome should not depend on context or mode.
4) Instructions should never fail silently.