1. Field of the Invention
This invention relates to isolating the code and/or data of one or more software modules within a computer system.
2. Description of the Related Art
The invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. For example, the computer readable media may comprise one or more CDs (Compact Discs), one or more DVDs (Digital Versatile Discs), some form of flash memory device, a computer hard disk and/or some form of internal computer memory, to name just a few examples. An embodiment of the invention, in which one or more computer program modules is embodied in one or more computer readable media, may be made by writing the computer program modules to any combination of one or more computer readable media. Such an embodiment of the invention may be sold by enabling a customer to obtain a copy of the computer program modules in one or more computer readable media, regardless of the manner in which the customer obtains the copy of the computer program modules. Thus, for example, a computer program implementing the invention may be purchased electronically over the Internet and downloaded directly from a vendor's web server to the purchaser's computer, without any transference of any computer readable media. In such a case, writing the computer program to a hard disk of the web server to make it available over the Internet may be considered a making of the invention on the part of the vendor, and the purchase and download of the computer program by a customer may be considered a sale of the invention by the vendor, as well as a making of the invention by the customer.
This invention may be implemented in a wide variety of computer systems, having a wide variety of hardware platforms and configurations and a wide variety of software platforms and configurations. If a computer system includes multiple software entities or software modules, or at least has the potential to contain multiple software modules, then the integrity of the computer system may be improved by implementing this invention to protect the code and/or data of one or more of the software modules from other software modules in the system.
Over the years, a variety of techniques have been used for executing multiple software modules within a computer system. Early computer systems could execute multiple software programs, but they could only execute one program at a time. Such computers might load one program into memory and execute it to completion or other termination, before proceeding to a subsequent program that would then be loaded into memory and executed. As another example, various multitasking operating systems (OSs) enable multiple programs (or selected portions thereof) to be loaded into memory at one time and executed in an alternating manner, according to a scheduling algorithm. Also, some processors include multithreading capabilities, which enable multiple threads of one or more programs to be executed simultaneously on a single processor. Finally, multiprocessor computer systems have also become commonplace, in which each of multiple processors can execute one or more threads all at the same time. This invention may be advantageously implemented in any of these types of systems, as well as other possible computer systems in which multiple software modules may be executed.
Such computer systems generally attempt to isolate the code and data of the different software modules within the computer system from each other, so that, for example, one software module cannot interfere with the execution of another software module by altering its code or data. Such isolation may be provided for code and/or data that is stored on a hard drive (or other secondary data storage means) and/or that is resident in main memory (or other primary data storage means). In this patent, the term “data” is generally used in a broad sense, to include data that is operated on by the instructions (code) of a software module as well as the contents of a stack and any other possible forms of data that are associated with a software module. As one example of the isolation of code and data, many systems implement a virtual addressing mechanism, in which different software modules within the system have different virtual address spaces, with each virtual address space generally being mapped to different portions of the physical address space of the computer system, so that the virtual addresses of a given software module are generally only mapped to physical addresses that contain the code or data of that particular software module. Virtual addressing mechanisms are described in greater detail below. A given software module may attempt to access every memory location in its own virtual address space, accessing every memory location to which it has access, and it will still only be able to access its own code and data (assuming that there is no shared memory). Thus, providing a virtual addressing mechanism provides some isolation between the code and data of multiple software modules in a computer system. Various other protection mechanisms may also be implemented in such computer systems to isolate the code and/or data of multiple software modules from one another.
Although the invention may be implemented in a wide variety of computer systems, having a wide variety of hardware and software platforms and configurations, the following description is generally limited to a single hardware platform for brevity. In particular, this description is generally limited to computer systems that include one or more processors having the “x86” architecture, which is described in the IA-32 Intel Architecture Software Developer's Manual (“the IA-32 Manual”) from Intel Corporation. Also for brevity, the following description is generally limited to computer systems running a Windows OS from Microsoft Corp. or a Linux OS, although there are certainly other OSs that operate on the x86 platform. A Windows OS from Microsoft Corp. may be a Windows XP OS or a Windows 2000 OS, for example, while a Linux OS may be a distribution from Novell, Inc. (SUSE Linux), Mandrakesoft S.A. or Red Hat, Inc. Based on the following description related to the x86 architecture and a Windows or Linux OS, a person of skill in the art will be able to implement the invention in a wide variety of other computer systems.
The x86 architecture provides two primary memory protection mechanisms that may be used by an OS (or other system software) to try to isolate the code and data of multiple tasks or processes that execute on the processor, namely a segmentation mechanism and a paging mechanism. The IA-32 Manual may be consulted for a detailed description of these protection mechanisms. The Windows and Linux OSs use the paging mechanism, but they generally don't take advantage of the segmentation mechanism. Instead, these OSs define segments that include the entire addressable range of the processor, so that the segmentation protection mechanism becomes ineffective in providing isolation between the code and data of multiple tasks. Thus, for simplicity, this discussion focuses on the paging mechanism of the x86 processor, which implements a virtual addressing mechanism as described briefly above and in greater detail below.
Very briefly for now, for Windows and Linux OSs, different user processes are generally given different virtual address spaces. The OS creates a different set of page tables (and a page directory) for each virtual address space, which maps the respective virtual addresses to physical addresses. Thus, the page tables for a given user process map that process's virtual addresses to the physical addresses that contain the code and data for that process. The page tables for the user processes also contain mappings for code and data of the OS, but the user processes cannot use these mappings because the user processes are executed at a Current Privilege Level (CPL) of 3 and these mappings are set to require a supervisor privilege level (a CPL of 0, 1 or 2). Otherwise, the page tables for a given user process generally only contain mappings to physical memory pages that contain that process's code and data. Therefore, a user process can generally only access its own code and data. Executing the user processes at a CPL of 3, also prevents the processes from modifying their own page tables. Otherwise, a process could add entries to its page tables that map to any physical address in the system, so that the process could give itself access to the code and data of other software modules, including other user processes and the OS.
Windows and Linux OSs generally provide adequate protection for the software modules in a computer system, so long as all of the software modules are well designed and well behaved, meaning that they are not attempting to circumvent the protection mechanism. Thus, many processes may be running concurrently in such a computer system, with the OS giving each process a share of the system resources, including processor time, memory space and hard disk space, without any of the processes interfering with the code or data of the other processes.
FIG. 1 illustrates a simple computer system 2A having multiple software modules. The computer system 2A includes system hardware 100A, an OS 20A, a first application 40A and a second application 40B. The system hardware 100A may be conventional hardware based on, for example, the x86 platform, and the OS 20A may be, for example, a Windows OS or a Linux OS. The applications 40A and 40B may be any applications designed to run on the system hardware 100A and the OS 20A. The OS 20A also includes a set of drivers 29A, which may be conventional drivers for the OS 20A, possibly including one or more drivers from a company that is different from the OS vendor (a third party vendor).
The OS 20A, in conjunction with the system hardware 100A, attempts to isolate the code and data of the applications 40A and 40B from one another. For example, the OS 20A and the system hardware 100A may implement a virtual addressing mechanism, as described above. As illustrated in FIG. 1, implementing such a protection mechanism may be characterized as establishing an isolation barrier 80B between the applications 40A and 40B, preventing (or at least hindering) one application from accessing the code and data of the other application. There may also be some code and/or data that is shared explicitly or transparently between the applications 40A and 40B. Techniques are known for allowing such sharing of code and data, while maintaining isolation between the applications 40A and 40B. For example, the OS 20A may mark physical memory pages that contain shared code or data as read only, such as when using a copy-on-write (COW) technique. The isolation barrier 80B may be referred to as an “OS isolation barrier” because it is implemented by the OS 20A, in conjunction with the system hardware 100A. The OS 20A, again in conjunction with the system hardware 100A, also establishes an OS isolation barrier 80A between the OS 20A and all applications in the system, including the applications 40A and 40B, so that the applications are prevented (or hindered) from directly accessing the code and data of the OS 20A. In the case of a Windows or Linux OS running on an x86 platform, the OS isolation barrier 80A is established by executing the applications in the system at a CPL of 3 and requiring a supervisor privilege level to access memory pages containing the code and data of the OS 20A.
Although the Windows and Linux OSs provide adequate isolation between software modules for computer systems that contain only well designed and well behaved software modules, malicious software modules have been known to wreak havoc in such computer systems by circumventing the protection mechanisms and engaging in all sorts of mischief. In particular, such malicious software modules have been known to breach the OS isolation barriers 80B and 80A, and corrupt the code and/or data of other applications in the system, and/or of the OS itself. Numerous security vulnerabilities have been discovered in the Windows OSs and, to a lesser extent, in the Linux distributions, and many of these vulnerabilities have been exploited by hackers using different types of malicious software, such as viruses, worms, etc. Microsoft Corp. acknowledges in its '006 patent (referenced below) that “open operating systems that allow users to easily install hardware and software . . . are inherently untrustworthy” (the '006 patent, paragraph [0004]). Poorly designed or implemented software may inadvertently bypass these protection mechanisms too and may also wreak havoc in a computer system. Although the description in this patent generally relates to malicious software, it also applies to software that inadvertently has the same or similar effects as malicious software.
Thus, hackers that exploit the vulnerabilities described above do so for a variety of reasons and with a variety of goals, some being relatively benign and others being quite destructive or disruptive. As one example, a malicious software module may be written and deployed that searches for sensitive data on a computer's hard drive or in its memory and transmits any such sensitive data back to the hacker that launched the malicious code. If the malicious software manages to execute at supervisor level (with a CPL of 0, 1 or 2), which is a common occurrence, then the malicious software may access a variety of system resources that are supposed to be safeguarded. For example, the malicious software can create its own page table entries, and obtain access to any address within the physical address space of the processor. The malicious software can then scan the entire physical memory for sensitive data, including memory that contains code and data of other software modules. A wide variety of other possibilities also exist.
Security threats such as these have been gaining greater notoriety, and it is widely accepted that something should be done to improve the security of the ubiquitous personal computer, and, in particular, there is a recognized need to improve the security for the vast number of computers based on the x86 architecture. Many people believe that software changes alone will not provide adequate protection. Accordingly, many different companies are working toward solutions that involve substantial changes to both the system hardware and the system software of a computer system. Many such security measures will also require substantial changes to application level software as well. Some of the security measures that have been or are being pursued by various companies are described below.
U.S. Pat. No. 6,507,904 (Ellison et al., “Executing Isolated Mode Instructions in a Secure System Running in Privilege Rings”, “the '904 patent”), which was assigned to Intel Corporation, describes a computer system in which a processor operates in either a normal execution mode or an isolated execution mode. Among other features, the computer system includes an isolated region in system memory that is protected by both the processor and a chipset of the computer system. Access to the isolated region is permitted only when using special bus cycles, referred to as isolated read and write cycles. The isolated read and write cycles may only be issued by the processor when it is executing in the isolated execution mode. Execution in the isolated execution mode is restricted, so that access to the isolated memory region is also restricted, accordingly.
U.S. Pat. No. 6,820,177 (Poisner, “Protected Configuration Space in a Protected Environment”, “the '177 patent”), which was also assigned to Intel Corporation, describes a computer system in which the physical address space encompasses a protected configuration space and a non-protected configuration space. Attempts to access addresses within the protected configuration space are redirected to protected configuration hardware that is external to the system memory. This protected configuration hardware holds control values, provides control information, and performs operations pertaining to a protected operating environment. Attempts to access the protected configuration space are permitted only if they are made by a processor, and only if they are made using a “protected command.” Restricting access to the protected configuration hardware purportedly enables the system to maintain a protected operating environment. The protected operating environment may include blocks of protected memory, which are apparently protected from any attempted access by non-processor devices.
U.S. Pat. No. 6,986,006 (Willman et al., “Page Granular Curtained Memory via Mapping Control”, “the '006 patent”), which was assigned to Microsoft Corporation, describes a method by which access to trusted memory is restricted using a paging mechanism, by not including mapping entries in page tables that map to physical memory pages that contain the trusted memory. The memory pages that contain the page tables are then restricted to read-only access when the processor is operating in a non-trusted mode to prevent non-trusted software from adding a new mapping entry or modifying an existing mapping entry to map to trusted memory. If non-trusted software attempts to write to a memory page containing a page table, a context switch is initiated into a page table entry edit module, which is trusted software. The page table entry edit module then ensures that the attempted write does not establish a mapping into trusted memory. The '006 patent does not specifically indicate how non-trusted software is prevented from changing the memory pages containing page tables to read/write access or from corrupting or supplanting the page table entry edit module to enable the non-trusted software to establish a mapping to trusted memory. The '006 patent does indicate, however, that the memory controller or other hardware may be able to restrict access to certain pages of physical memory under the control of the page table entry edit module. A new hardware platform or substantial changes to an existing hardware platform would presumably be necessary to implement such a restriction.
U.S. Pat. No. 7,058,768 (Willman et al., “Memory Isolation Through Address Translation Data Edit Control”, “the '768 patent”), which is a continuation-in-part of the '006 patent and which was also assigned to Microsoft Corporation, is similar to the '006 patent, although the '768 patent uses different terminology and it goes into greater detail in some areas. The '768 patent describes a computer system that includes a trusted environment and an untrusted environment. A trusted component in the trusted environment purportedly ensures that, when the system is executing in the untrusted environment, no active address translation map includes an address mapping that maps to isolated memory, so that the isolated memory is not accessible to untrusted components. Again, the '768 patent does not specify how the trusted environment is established or maintained, but implementing the computer system described in the '768 patent presumably requires substantial hardware changes.
U.S. Patent Application Publication No. 2004/0205203 (Peinado et al., “Enforcing Isolation Among Plural Operating Systems”, “the '203 application”), which was also assigned to Microsoft Corporation, describes a method for restricting the physical addresses that are accessible to Direct Memory Access (DMA) devices in a computer system in which multiple OSs run. In this method, a security kernel maintains a DMA exclusion vector that specifies which physical addresses are accessible to different DMA devices. A hardware device, referred to as a regulator, enforces the physical address restrictions specified in the DMA exclusion vector. The '203 application also briefly mentions the possibility of using a shadow page table technique to prevent one OS from accessing the private data of another OS, and the '203 application mentions the more general possibility of employing an “adjunct memory access control scheme.”
U.S. Pat. No. 6,651,171 (England et al., “Secure Execution of Program Code”, “the '171 patent”), which was also assigned to Microsoft Corporation, describes a system in which hardware enforces a restricted memory arrangement. Multiple curtained memory rings are arranged in a hierarchical manner, similar to the protection rings of the x86 architecture. Different code and data are associated with each of the memory rings. Software in more-privileged rings can access code and data in less-privileged rings, but software in less-privileged rings cannot access code or data in more-privileged rings. Also, there may be multiple subrings within a given ring. Software within a given ring can also access code and data within its own ring, except that it cannot access code or data within a different subring.
U.S. Patent Application Publication No. 2003/0093686 (Barnes et al., “Memory Management System and Method Providing Linear Address Based Memory Access Security”, “the '686 application”), which was assigned to Advanced Micro Devices, Inc., describes a Memory Management Unit (MMU) that includes a Security Check Unit (SCU) that receives a linear address generated during the execution of a current instruction. The linear address has a corresponding physical address residing within a selected memory page. The SCU uses the linear address to access one or more security attribute data structures located in the memory to obtain a security attribute of the selected memory page. The SCU compares a numerical value conveyed by a security attribute of the current instruction to a numerical value conveyed by the security attribute of the selected memory page, and produces an output signal dependent upon a result of the comparison. The MMU accesses the selected memory page dependent upon the output signal. The security attribute of the selected memory page and the security attribute of the current instruction may each include a security identification (SCID) value indicating a security context level of the selected memory page or the current instruction, respectively.
U.S. Pat. No. 6,823,433 (Barnes et al., “Memory Management System and Method for Providing Physical Address Based Memory Access Security”, “the '433 patent”), which was also assigned to Advanced Micro Devices, Inc., discloses a MMU that is similar to the MMU disclosed in the '686 application. A security unit in the MMU of the '433 patent uses a physical address, instead of a linear address, to access security attribute data structures to obtain a security attribute of a selected memory page. Otherwise, the disclosure of the '433 patent is substantially similar to the disclosure of the '686 application.
U.S. Pat. No. 7,073,059 (Worley, J R. et al., “Secure Machine Platform that Interfaces to Operating Systems and Customized Control Programs”, “the '059 patent”), which was assigned to Hewlett Packard Company, describes a “Secure Platform” (SP), which includes a software layer that executes at a privileged level on a modern processor architecture, such as the IA-64 processor architecture from Intel Corporation. The SP interfaces with one or more OSs and customized control programs, and allows them to access non-privileged machine instructions and registers. However, the OSs and customized control programs purportedly have no direct access to privileged instructions and registers and firmware interfaces. Instead, the SP allows the OSs and customized control programs to invoke software routines that provide control of the hardware, without exposing the privileged machine instructions and registers. The SP also organizes the resources of the system into one or more disjoint, mutually isolated partitions, called “domains.” A single OS and all user-level processes managed by that OS together comprise a domain, and each domain is allocated a separate portion of virtual memory, along with other system resources. The SP employs the region registers and region identifiers, along with protection keys, of the IA-64 processor architecture to partition memory between the different domains.
With respect to the ubiquitous x86 platform, each of the possible security measures described above would require substantial hardware changes or an entirely new hardware platform. They would also require substantial changes to existing software platforms, including system software and possibly application software. Applications in some of these implementations might also have limited access to input/output devices because of a limited supply of trusted device drivers. A widespread transition from the x86 platform to a new hardware platform will likely be a slow, gradual process. The amount of money that is invested in computer hardware and software based on the x86 architecture throughout the world is enormous. Many individuals, businesses, schools, governments and other organizations will be reluctant to scrap their current x86 systems, along with all the software that currently runs on x86 systems, and replace them with new technology. Even if a new, more secure and widely accepted hardware platform were available today, it would still take a long time for the new hardware to become anywhere near as widespread as the x86 platform is today. In the meantime, a large number and proportion of computers would remain vulnerable to the security threats described above.
Also, even those individuals and organizations that quickly adopt the new hardware and software technology may still be susceptible to adverse effects resulting from lingering vulnerabilities of x86 computers. For example, a malicious software module may attack an x86-based server computer running a web application. If the malicious software takes down the server computer, any client computer attempting to access the web application will be adversely affected no matter how secure the client computer is. As another example, a malicious software module may infect a large number of x86 computers connected to the Internet. The many instances of the malicious software module on all the x86 computers may then mount a coordinated denial of service attack on a particular website on the Internet. In this case, the server computer(s) that are hosting the website and any bonafide client computers trying to access the website may be adversely affected by the attack, again, regardless of the technology implemented in either the server computer(s) or the bonafide client computers.
As a final example, even if an individual or organization has spent the money to replace all of its own computers and software with the new technology, sensitive information of the individual or organization may still reside on some external computer that remains vulnerable to the security threats described above. Suppose, for example, that an individual forks out the money to buy a new computer system based on a new hardware and software platform, so that all the sensitive information on the individual's computer system is now relatively secure. Suppose further, however, that the individual's bank (or any other organization that has sensitive information of the individual, such as some small company running an obscure Internet website from which the individual has made a purchase) has thus far continued to use its x86 computers instead of investing in the new technology. Again, if malicious software is able to exploit a vulnerability in the bank's computer system, a hacker may be able to steal sensitive information of the individual no matter what technology the individual is using.
What is needed, therefore, is a security measure that can be implemented more quickly and easily, without requiring such a large investment in new computer hardware and software. More particularly, what is needed is a solution that provides better isolation for the code and/or data of software modules within a computer system, but that can be implemented in software, without any hardware changes and with, at most, only minor software changes.
There are some proposed security measures that may be implemented primarily in software. In particular, there are some such measures that use virtualization technology to create multiple virtual machines (VMs), where different software modules run in different VMs. It is widely recognized that a well-designed and implemented virtualization layer can generally provide much greater isolation between multiple VMs than a general OS can provide between multiple software modules. For example, U.S. Pat. No. 6,922,774 (Meushaw et al., “Device for and Method of Secure Computing Using Virtual Machines”, “the '774 patent”), which was assigned to the National Security Agency of the U.S. Government, describes a computer system that includes a Virtual Machine Monitor (VMM) that allows a user to create a number of VMs. The system includes a user-definable number of non-sensitive VMs and a user-definable number of sensitive VMs, all of which are isolated from one another by the virtualization technology. Each sensitive VM provides access to a secure area in a computer system that is accessible only through encrypted and/or authenticated connections. An encryption VM is created for and connected to each sensitive VM, where each encryption VM provides encryption capabilities, as well as possibly digital signature and key exchange capabilities. The computer system may also include a server connected to each VM in the system, where the server may be another VM or a stand-alone device. Each VM in the system can send information to the server, and the server can send information to any VM in the system, except as limited by user-definable rules for when a transfer is, or is not, appropriate to be transferred from one VM to another. Thus, the server allows information to be transferred from one VM to another when appropriate while maintaining isolation between VMs.
Another proposed security measure that takes advantage of the isolation provided by implementing multiple VMs was described in a technical paper entitled “Terra: A Virtual Machine-Based Platform for Trusted Computing,” which was submitted to and presented at the Symposium on Operating Systems Principles, October 19-22, 2003, by Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum and Dan Boneh (“the Terra paper”). The Terra paper describes a trusted VMM that partitions a single tamper-resistant, general-purpose platform into multiple isolated VMs. Existing applications and OSs can each run in a standard (open-box) VM that provides the semantics of today's open platforms. Applications can also run in their own closed-box VMs that provide the functionality of running on a dedicated closed platform. Among various other aspects of the proposed security measure, VMs on a single physical machine communicate with one another over virtualized standard input/output interfaces such as network interface cards, serial ports, etc.
FIG. 2 illustrates a general computer system 2B in which multiple VMs are implemented to isolate multiple software modules from one another. The computer system 2B includes system hardware 100B, which may be conventional hardware, such as hardware based on the x86 platform. The system hardware 100B may be substantially the same as the system hardware 100A of FIG. 1, or it may be substantially different. A virtualization software 200A executes on the system hardware 100B and supports a plurality of VMs, such as a first VM 300A and a second VM 300B, in a known manner. The virtualization software 200A may comprise a VMM, for example, such as a VMM as implemented in a virtualization product of VMware, Inc., the assignee of this patent. Such a VMM and other possible units of the virtualization software 200A are described in greater detail below.
In supporting the VM 300A, the virtualization software 200A virtualizes a virtual system hardware 310A, which may be based on an existing hardware platform, such as the x86 platform. An OS 20B, along with a set of drivers 29B, run on the virtual system hardware 310A. The OS 20B may be any OS designed to run on the hardware platform virtualized in the virtual hardware 310A. For example, if the virtual hardware 310A is based on the x86 platform, the OS 20B may be a Windows OS or a Linux OS. The set of drivers 29B may be conventional drivers for the OS 20B. A first application 40C and a second application 40D run on the OS 20B. The applications 40C and 40D may be any applications designed to run on the platform of the virtual hardware 310A and the OS 20B. Similar to the OS 20A of FIG. 1, the OS 20B, in conjunction with the virtual system hardware 310A, attempts to isolate the code and data of the applications 40C and 40D from one another, establishing an OS isolation barrier 80B between the applications 40C and 40D. Also similar to the OS 20A of FIG. 1, the OS 20B, again in conjunction with the virtual system hardware 310A, also establishes an OS isolation barrier 80A between the OS 20B and all applications in the VM 300A, including the applications 40C and 40D. Thus, the VM 300A may be substantially the same as the computer system 2A, except that the virtual system hardware 310A is virtual hardware, virtualized by the virtualization software 200A, instead of physical hardware.
In supporting the VM 300B, the virtualization software 200A virtualizes a virtual system hardware 310B, which may be based on an existing hardware platform, such as the x86 platform. An OS 20C, along with a set of drivers 29C, run on the virtual system hardware 310B. The OS 20C may be any OS designed to run on the hardware platform virtualized in the virtual hardware 310B. For example, if the virtual hardware 310B is based on the x86 platform, the OS 20C may be a Windows OS or a Linux OS. The set of drivers 29C may be conventional drivers for the OS 20C. A first application 40E and a second application 40F run on the OS 20C. The applications 40E and 40F may be any applications designed to run on the platform of the virtual hardware 310B and the OS 20C. Again, similar to the OS 20A of FIG. 1, the OS 20C, in conjunction with the virtual system hardware 310B, attempts to isolate the code and data of the applications 40E and 40F from one another, establishing an OS isolation barrier 80B between the applications 40E and 40F. Also similar to the OS 20A of FIG. 1, the OS 20C, again in conjunction with the virtual system hardware 310B, establishes an OS isolation barrier 80A between the OS 20C and all applications in the VM 300B, including the applications 40E and 40F. Thus, again, the VM 300B may be substantially the same as the computer system 2A, except that the virtual system hardware 310B is virtual hardware, virtualized by the virtualization software 200A, instead of physical hardware.
The virtualization software 200A isolates the VMs in the computer system 2B from one another. For example, the virtualization software 200A allows software within the VM 300A to access portions of physical memory in the system hardware 100B and it allows software within the VM 300B to access other portions of the physical memory. The virtualization software 200A maps attempted memory accesses from the respective VMs 300A and 300B to different portions of the physical memory, ensuring that no memory address generated by software in one VM can access code or data of another VM. In a similar manner, the virtualization software 200A maps attempted hard disk accesses from the respective VMs 300A and 300B to different portions of one or more hard disks in the system hardware 100B, ensuring that one VM cannot access the hard disk space of another VM.
The virtualization software 200A also takes other precautions to isolate the VMs in the computer system 2B from one another, and from the virtualization software 200A, itself. For example, U.S. patent application Ser. No. 10/917,713 (Agesen et al., “Restricting Memory Access to Protect Data when Sharing a Common Address Space”, “the '713 application”), which has been assigned to the same assignee as this patent, and which is hereby incorporated herein by reference, describes methods that may be used to enable a VMM to occupy a portion of a linear address space of a VM, while preventing the VM from accessing the memory of the VMM. There are also various other methods that may be used to enable virtualization software to coexist with VMs in a virtual computer system, while protecting or isolating the virtualization software from software within the VMs. The virtualization software 200A may also prevent software within the VMs 300A and 300B from directly accessing certain hardware resources to further isolate the VMs from one another and from the virtualization software 200A. For example, the virtualization software 200A may prevent software within the VMs 300A and 300B from directly accessing a Direct Memory Access (DMA) device to prevent the possibility that the DMA device could be used to access either the hard disk space or the memory of other VMs or of the virtualization software itself. Various other precautions may also be taken, depending on the particular implementation. In addition to the precautions described thus far, the underlying system hardware may provide further support for isolating the VMs from each other and from the virtualization software. For example, Intel Corporation has implemented its Virtualization Technology (Intel VT), and Advanced Micro Devices, Inc. has implemented its AMD Virtualization (AMD-V) or Secure Virtual Machine (SVM), which provide hardware enhancements to facilitate the implementation of virtual computer systems.
Thus, the virtualization software 200A, in conjunction with the system hardware 100B, may be said to establish a first isolation barrier 280B between the VMs 300A and 300B and a second isolation barrier 280A between the virtualization software 200A and all VMs in the computer system 2B, including the VMs 300A and 300B. The isolation barriers 280A and 280B may be referred to as “virtualization barriers” because they are implemented by the virtualization software 200A, in conjunction with the system hardware 100B. The isolation barriers 280A and 280B may also be referred to as virtualization barriers because they are established through the virtualization of hardware resources, such as the virtualization of system memory.
It is widely recognized that virtualization techniques can generally provide better security and more effective isolation between multiple software modules than general OSs provide. Thus, the virtualization barriers 280A and 280B of FIG. 2 can generally provide much better isolation between the multiple VMs 300A and 300B and the virtualization software 200A than the OS isolation barriers 80A and 80B of FIG. 1 provide between the multiple applications 40A and 40B and the OS 20A. This improved isolation can be attributed to a variety of factors, depending on the particular situation. For example, OSs, such as the OS 20A, generally provide an Application Programming Interface (API) for use by applications, such as the applications 40A and 40B. These APIs can be used by application software first to discover and then to exploit vulnerabilities within the OS. Virtualization software, in contrast, generally has no such interface, or at least a more limited and/or restricted interface, for use by the software within a VM. Also, virtualization software generally does not need to rely on the integrity of third party device drivers. In contrast, general OSs often allow third party device drivers to execute at a most privileged level on the system hardware, so that they can access restricted hardware resources. If such a device driver contains malicious software, the driver can compromise the integrity of the entire computer system. Also, virtualization software is generally smaller and, in some ways, less complex than a general OS, such as a Windows or Linux OS, which generally leads to a smaller number of vulnerabilities that may be exploited to compromise the integrity of the computer system. Thus, virtualization software is likely to have fewer vulnerabilities than a general OS, and, more importantly, by the very nature of virtualizing a computer system, the virtualization software is much more isolated from software within a VM than a general OS is from other software within a computer system, making it much harder to discover and exploit any possible vulnerabilities.
Although computer systems that establish multiple VMs and that run different software modules within the different VMs generally provide better isolation for the software modules than do general OSs, such virtual computer systems have other limitations. First, if the software within a VM becomes corrupted by malicious software, the same problems described above relative to non-virtualized computer systems can occur within the affected VM. All software modules within the particular VM may be compromised by the malicious software. This scenario may be seen in FIG. 2. Suppose a malicious software module is able to execute within the VM 300A. If the malicious software is able to circumvent the OS isolation barriers 80A and/or 80B within that VM, then the malicious software can corrupt the OS 20B and/or the applications 40C and 40D. The virtualization barriers 280A and 280B will generally contain the malicious software within the VM 300A, however, so that it is not able to corrupt the virtualization software 200A or the software within the VM 300B. Thus, while the computer system 2B of FIG. 2 is able to limit the corruption to the VM 300A, the software within the VM 300A may be no more secure than the software within the computer system 2A of FIG. 1, depending on the circumstances. Of course, more VMs can be created within the virtual computer system 2B of FIG. 2 to further isolate the software modules within the computer system, but this increased isolation aggravates a second limitation of these virtual computer systems.
Multiple VMs within a computer system are generally similar to multiple physical computer systems. The multiple VMs generally have, at most, only limited communication and interaction with one another. For example, in the computer system of the '774 patent, the multiple VMs in the system can communicate with each other by sending information to a server, which can send the information on to another VM in the system, except as limited by user-definable rules. In the computer system described in the Terra paper, VMs on a single physical machine can communicate with one another over virtualized standard input/output interfaces such as network interface cards, serial ports, etc. Many software modules within a computer system, however, require more effective interaction or communication with other software modules. For example, multiple software modules may need to use shared memory to facilitate fast and efficient communication of data, or a software module may need to call a subroutine of another software module.
Another disadvantage of a computer system in which multiple VMs are used to isolate multiple software modules is that setting up and using such a system generally takes significantly more time and effort than a computer system in which multiple software modules and a general OS run directly on physical hardware. Individuals and organizations may be reluctant to adopt a multiple VM solution or they may not use such a solution consistently enough. Anytime such a solution is not used, and multiple software modules are run directly on a physical computer system or within a single VM, the risk of corruption by a malicious software module is increased.
What is needed therefore is a computer system for executing multiple software modules that provides improved security, such as is provided by the virtualized computer systems described above, while also providing more efficient and effective communication and/or interaction between multiple software modules. It would also be advantageous if such a computer system were easy to configure, use and maintain.