HK1216679B - Page fault injection in virtual machines - Google Patents

Description

Page fault injection in virtual machines

Related applications

This application claims the benefit of the filing date of U.S. Provisional Patent Application No. 61/847,538, filed on July 17, 2013, entitled “Page Fault Injection In Virtual Machines,” which is incorporated herein by reference in its entirety.

Background Art

The present invention relates to systems and methods for protecting computer systems from malware.

Malicious software (also known as malicious software) affects a large number of computer systems worldwide. In its many forms, such as computer viruses, worms, rootkits, and spyware, malicious software presents a serious risk to millions of computer users, exposing them to loss of data and sensitive information, identity theft, and loss of productivity, among other things.

Hardware virtualization technology allows the creation of simulated computer environments, often called virtual machines, that behave like physical computer systems in many ways. In typical applications, such as server consolidation and Infrastructure as a Service (IaaS), several virtual machines can run simultaneously on the same physical machine, sharing hardware resources between them, thereby reducing investment and operating costs. Each virtual machine can run its own operating system and/or software applications separately from the other virtual machines. Due to the steady spread of malware, each virtual machine operating in such an environment potentially requires malware protection.

Virtualization solutions commonly used in the field include a hypervisor, also known as a virtual machine monitor. This consists of a layer of software that operates between the computing hardware and the virtual machine's operating system (OS) and has greater processor privileges than the corresponding OS. Anti-malware operations can be performed at the hypervisor's privilege level. While such a configuration can increase security, it introduces an additional layer of complexity and can incur significant computational costs.

There is considerable interest in developing effective, robust, and scalable anti-malware solutions for hardware virtualization platforms.

Summary of the Invention

According to one aspect, a host system includes a hardware processor configured to operate a hypervisor and a memory introspection engine. The hypervisor is configured to expose a virtual machine including a virtualized processor and virtualized memory, the virtual machine being configured to execute a target process using the virtualized processor. The memory introspection engine executes outside the virtual machine and is configured to determine, based on a page table of the virtual machine, whether a target page of a virtual memory space of a target process has been swapped out of the virtualized memory. In response, when the target page has been swapped out of the virtualized memory, the memory introspection engine directly injects a page fault into the virtual machine, causing the operating system of the virtual machine to map the target page to a page of the virtualized memory.

According to another aspect, a method includes executing a hypervisor using at least one hardware processor of a host system, the hypervisor being configured to expose a virtual machine including a virtualized processor and virtualized memory, the virtual machine being further configured to execute a target process using the virtualized processor. The method further includes determining, using the at least one hardware processor, whether a target page of a virtual memory space of the target process has been swapped out of the virtualized memory, and in response, injecting, using the at least one hardware processor, a page fault directly into the virtual machine when the page has been swapped out of the virtualized memory, the page fault causing an operating system of the virtual machine to map the target page to a page of the virtualized memory.

According to another aspect, a non-transitory computer-readable medium stores instructions that, when executed by at least one hardware processor of a host system, cause the host system to form a memory introspection engine, wherein the host system is further configured to execute a hypervisor that exposes a virtual machine including a virtualized processor and virtualized memory, the virtual machine configured to execute a target process using the virtualized processor. The memory introspection engine executes externally to the virtual machine and is configured to determine, based on a page table of the virtual machine, whether a target page of a virtual memory space of the target process is swapped out of the virtual memory, and in response, directly inject a page fault into the virtual machine when the target page is swapped out of the virtualized memory, the page fault causing an operating system of the virtual machine to map the target page to a page of the virtualized memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and advantages of the present invention will be better understood after reading the following detailed description and after referring to the accompanying drawings, in which:

1 shows an exemplary set of virtual machines exposed by a hypervisor executing on a host system, and a memory introspection engine that protects the set of virtual machines from malware, according to some embodiments of the invention.

FIG2 shows an exemplary hardware configuration of a host system according to some embodiments of the present invention.

3 shows an exemplary configuration of virtualized hardware exposed to a guest virtual machine according to some embodiments of the present invention.

4 illustrates an exemplary layering of software objects executing on a host system at various processor privilege levels, according to some embodiments of the invention.

5 shows an exemplary mapping of memory addresses and exemplary swapping of memory pages in and out of virtualized memory according to some embodiments of the invention.

6 shows an exemplary sequence of steps performed by a memory introspection engine to protect a virtual machine from malware, according to some embodiments of the invention.

7 shows an exemplary sequence of steps performed by storage introspection to implement direct page fault injection, according to some embodiments of the invention.

8 shows an exemplary sequence of steps illustrating application of the methods of FIGs. 6-7, according to some embodiments of the invention.

9 shows an exemplary sequence of steps illustrating another application of the method of FIGs. 6-7, according to some embodiments of the invention.

10 illustrates an exemplary determination of a set of virtual addresses of memory pages containing data for a target process, according to some embodiments of the invention.

DETAILED DESCRIPTION

In the following description, it should be understood that all listed connections between structures may be directly operable connections or indirectly operable connections through intermediate structures. A set of elements includes one or more elements. Any listing of elements is understood to refer to at least one element. A plurality of elements includes at least two elements. Unless otherwise required, any described method steps need not necessarily be performed in the specific order described. A first element (for example, data) derived from a second element includes a first element that is identical to the second element, and also includes a first element generated by processing the second element and, optionally, other data. Making a determination or decision based on a parameter includes making a determination or decision based on the parameter and, optionally, other data. Unless otherwise specified, an indicator of some quantity/data may be the quantity/data itself or an indicator different from the quantity/data itself. Unless otherwise specified, a process is an instance of a computer program (such as an application or part of an operating system) and is characterized by having at least one execution thread and a segment of virtual memory assigned to it by the operating system, wherein the corresponding segment includes executable code. Unless otherwise specified, a page represents the smallest unit of a virtual machine that is individually mapped to the physical memory of a host system. Unless otherwise specified, directly injecting a page fault into a virtual machine includes inducing a page fault event within the virtualized processor of the corresponding virtual machine without assistance from the operating system or other software executing within the corresponding virtual machine. Such direct injection does not preclude the operating system or other software from taking action in response to the injected page fault, such as to handle the page fault. Computer-readable media includes non-transitory media such as magnetic storage media, optical storage media, and semiconductor storage media (for example, hard drives, optical disks, flash memory, DRAM), as well as communication links such as conductive cables and fiber optic links. According to some embodiments, the present invention provides, among other things, a computer system comprising hardware (for example, one or more processors) programmed to perform the methods described herein, and a computer-readable medium encoding instructions to perform the methods described herein.

The following description illustrates embodiments of the invention by way of example and not necessarily by way of limitation.

FIG1 shows an exemplary configuration of a host system 10 that utilizes hardware virtualization for malware protection, according to some embodiments of the present invention. Host system 10 may represent an enterprise computing device (e.g., an enterprise server) or an end-user device (e.g., a personal computer or smartphone). Other exemplary host systems include entertainment devices (e.g., a TV or game console) or any other device with memory and a processor that requires malware protection. In the example of FIG1 , host system 10 executes a set of client virtual machines 32 a-b exposed by a hypervisor 30. A virtual machine (VM) comprises an abstraction (e.g., a software emulation) of an actual physical machine/computer system capable of running an operating system and other applications. Hypervisor 30 includes software configured to generate multiple virtualized devices (e.g., virtual processors and virtual memory controllers) and present these virtualized devices to software as replacements for the actual physical devices of host system 10. In some embodiments, hypervisor 30 allows multiplexing (sharing) of hardware resources of host system 10 by multiple virtual machines. Hypervisor 30 can further manage this multiplexing so that each VM operates independently and is unaware of other VMs executing simultaneously on host system 10. Examples of popular hypervisors include VMware vSphere ^™ from VMware, Inc. and the open source Xen hypervisor, among others.

Each VM 32a to b can execute a client operating system (OS) 34a to b, respectively. A set of exemplary applications 42a to d generally represent any software application, such as word processing, image processing, media player, database, calendar, personal contact management, browser, game, audio communication, data communication, and anti-malware applications, among others. Operating systems 34a to b can include any widely available operating system, such as Microsoft or Android ^™ , among others. Each OS provides an interface between the applications executing within the virtual machine and the virtualized hardware devices of the corresponding VM. In the following description, software executing on the virtual processor of a virtual machine is considered to be executed within the corresponding virtual machine. For example, in the example of FIG. 1 , applications 42a to b are considered to be executed within client VM 32a, while applications 42c to d are considered to be executed within client VM 32b. In contrast, hypervisor 30 is considered to be executed outside or below client VMs 32a to b.

In some embodiments, hypervisor 30 includes a memory introspection engine 40 configured to perform anti-malware operations as described further below. Engine 40 may be incorporated into hypervisor 30, or may be delivered as a software component that is distinct and independent from hypervisor 30 but executes at a substantially similar processor privilege level as hypervisor 30. A single engine 40 may be configured to protect multiple VMs executing on host system 10 from malware.

FIG2 shows an exemplary hardware configuration of a host system 10. System 10 includes a set of physical devices, including a processor 12, a memory unit 14, a set of input devices 16, a set of output devices 18, a set of storage devices 20, and a set of network adapters 22, all of which are connected by a controller hub 24. In some embodiments, processor 12 comprises a physical device (e.g., a multi-core integrated circuit formed on a semiconductor substrate) that is configured to perform computations and/or logical operations on a set of signals and/or data. In some embodiments, such logical operations are delivered to processor 12 in the form of a sequence of processor instructions (e.g., machine code or other type of software). Memory unit 14 may include volatile computer-readable media (e.g., RAM) that stores data/signals accessed or generated by processor 12 in the course of implementing the instructions.

Input devices 16 may include a computer keyboard, mouse, and microphone, among others, including corresponding hardware interfaces and/or adapters, allowing a user to enter data and/or instructions into host system 10. Output devices 18 may include a display device (e.g., a monitor and speakers, among others), as well as hardware interfaces/adapters (e.g., a graphics card) to allow host system 10 to communicate data to the user. In some embodiments, input devices 16 and output devices 18 may share a common piece of hardware, such as in the case of a touchscreen device. Storage device 20 includes computer-readable media that enables non-volatile storage, reading, and writing of software instructions and/or data. Exemplary storage devices 20 include magnetic and optical disks and flash memory storage devices, as well as removable media such as CD and/or DVD disks and drives. A set of network adapters 22 enables host system 10 to connect to a computer network and/or to other devices/computer systems. Controller hub 24 represents multiple system, peripheral, and/or chipset buses and/or all other circuitry that enables communication between processor 12 and devices 14, 16, 18, 20, and 22. For example, controller hub 24 may include a memory controller, an input/output (I/O) controller, and an interrupt controller, among other things. In another example, controller hub 24 may include a north bridge that connects processor 12 to memory 14 and/or a south bridge that connects processor 12 to devices 16, 18, 20, and 22.

1 , hypervisor 30 may create multiple virtualized devices, each of which emulates the physical hardware devices of system 10. Hypervisor 30 may further assign a set of virtualized devices to each VM 32 a-b and control scheduling, signaling, and communication so that VMs 32 a-b can simultaneously use processor 12 and other hardware devices. Performing such operations, such as exposing VMs 32 a-b, is also known in the art.

FIG3 shows an exemplary configuration of a virtual machine 32 as exposed by a hypervisor 30. VM 32 may represent, for example, any of VMs 32a-b of FIG1 . VM 32 includes a virtualized processor 112, a virtualized memory unit 114, a virtualized input device 116, a virtualized output device 118, a virtualized storage device 120, a virtualized network adapter 122, and a virtualized controller hub 124. Virtualized processor 112 emulates at least some of the functionality of processor 12 and is configured to receive processor instructions forming part of software (e.g., an operating system and other applications) for execution. Software executed using processor 112 is considered to be executed within virtual machine 32. In some embodiments, virtualized memory unit 114 includes an addressable space for storing and retrieving data used by virtualized processor 112. Other virtualized devices (e.g., virtualized input, output, storage, etc.) emulate at least some of the functionality of corresponding physical devices of host system 10. Virtualized processor 112 can be configured to interact with such devices as if they were physical devices. For example, software executing within VM 32 can send and/or receive network traffic via virtualized network adapter 122. In some embodiments, hypervisor 30 can expose only a subset of virtualized devices to VM 32 (e.g., only virtualized processor 112, virtualized memory 114, and a portion of hub 124). Hypervisor 30 can also expose some hardware devices of host system 10 to be dedicated to selected VMs. In one such example, VM 32a ( FIG. 1 ) may have dedicated input devices 16 and output devices 18, but lack a virtualized network adapter. Meanwhile, VM 32b may have dedicated network adapter 22.

FIG4 illustrates the layering of software objects executing on host system 10, according to some embodiments of the present invention. FIG4 is presented from the perspective of processor privilege levels (also known in the art as layers or protection rings). In some embodiments, hypervisor 30 controls processor 12 at the highest privilege level (e.g., VMXroot, also known as ring-1 or root mode, on platforms that support virtualization), creating a hardware virtualization platform that virtual machine 32 exposes to other software executing on host system 10. An operating system 34 (e.g., OS 34a-b in FIG2 ) executes within the virtual environment of VM 32, with lesser processor privileges than hypervisor 30 (e.g., ring 0 or kernel mode on Intel platforms). A set of applications 42e-f executes at lesser processor privileges than OS 34 (e.g., ring 3 or user mode). Some applications 42e-f may execute at a kernel privilege level (e.g., driver 36 installed by application 42f; exemplary driver 36 performs anti-malware operations, such as detecting malware-indicative behavior in software objects and/or detecting malware-indicative signatures within software objects). Similarly, portions of OS 34 may execute in user mode (ring 3).

In some embodiments, introspection engine 40 executes at substantially the same processor privilege level as hypervisor 30 and is configured to perform introspection of a virtual machine (e.g., VM 32) executing on host system 10. Introspection of a VM or a software object executing within a corresponding VM may include analyzing the behavior of the corresponding software object, such as identifying a set of operations performed by the object (e.g., issuing a system call, accessing the OS's registry, downloading a file from a remote location, writing data to a file, etc.). Introspection may further include determining the address of a memory segment containing a portion of the software object; accessing the corresponding memory segment; and analyzing the contents stored within the corresponding memory segment. Other examples of introspection include intercepting and/or restricting access to such memory segments by certain processes, for example, to prevent a process from overwriting code or data used by another process. In some embodiments, objects selected by engine 40 for introspection include processes, instruction streams, registers, and data structures (e.g., page tables and driver objects of the corresponding VM), among others.

To perform introspection of VM 32 in a configuration such as that illustrated in FIG1 (i.e., from outside the corresponding VM), some embodiments of engine 40 utilize the memory mapping structures and mechanisms of processor 12. Virtual machines typically operate with virtualized physical memory (e.g., memory 114 in FIG3 , also referred to in the art as guest physical memory). Virtualized physical memory comprises an abstract representation of actual physical memory 14, for example, as a contiguous space of virtualized addresses assigned to each guest VM, portions of which are mapped to addresses within physical memory 14 and/or physical storage devices 20. In systems configured to support virtualization, such mapping is typically implemented via a dedicated data structure controlled by processor 12, known as a second-level address translation (SLAT). Popular SLAT implementations include extended page tables (EPTs on platforms) and nested page tables (NPTs on platforms). In such systems, virtualized physical memory may be divided into units known in the art as pages, which represent the smallest unit of virtualized physical memory that is individually mapped to physical memory via a mechanism such as an EPT and/or NPT. That is, the mapping between physical and virtualized physical memory is performed at a page granularity. All pages typically have a predetermined size, for example, 4 kilobytes, 2 megabytes, etc. The division of virtualized physical memory into pages is typically configured by the hypervisor 30. In some embodiments, the hypervisor 30 also configures the EPT/NPT and, therefore, the mapping between physical memory and virtualized physical memory. The actual mapping (translation) of virtualized physical memory addresses to physical memory addresses may include looking up the physical memory address in a translation lookaside buffer (TLB) of the host system 10. In some embodiments, address translation includes performing a page walk, which includes a set of consecutive address lookups in a set of page tables and/or page directories, and performing calculations, such as adding a page offset to the address associated with the corresponding page.

Some hardware configurations allow hypervisor 30 to selectively control access to data within each page stored in physical memory 14, for example, by setting read, write, and/or execute access rights for the corresponding page. Such rights can be set, for example, by modifying an entry for the corresponding page within the EPT or NPT. Hypervisor 30 can thus select which software object can access the data stored at the address within each page and can indicate which operations are permitted with the corresponding data, for example, read, write, or execute. An attempt by a software object executing within a VM to perform an operation (e.g., writing data to a page for which the object does not have corresponding rights or executing code from a page marked as non-executable) can trigger a virtual machine exit event (e.g., a VMExit event on Intel platforms). In some embodiments, a virtual machine exit event transfers control of the processor from the VM executing the corresponding software object to hypervisor 30. This transfer can allow software executing at the processor privilege level of hypervisor 30 to intercept unauthorized write or execute attempts. In some embodiments, introspection engine 40 performs such introspection as part of anti-malware operations.

In some embodiments, OS 34 configures virtual memory space for a process (e.g., applications 42e to 42f in FIG. 4 ) by, for example, maintaining a mapping (address translation) between the corresponding virtual memory space of VM 32 and virtualized physical memory using a page table mechanism. In some embodiments, the process virtual memory space is also divided into pages, which represent the smallest unit of virtual memory that is individually mapped to virtualized physical memory by OS 34. That is, virtualization of virtualized physical memory mapping is performed with page granularity.

FIG5 illustrates an exemplary mapping of memory addresses in an embodiment such as that shown in FIG4 . A software object (e.g., an application, process, or portion of an operating system executing within a guest VM 32) is assigned virtual memory space 214a by guest OS 34. When the software object attempts to access the contents of exemplary memory page 60a of space 214a, the address of page 60a is translated by the virtualization processor of guest VM 32 into the address of page 60b of virtualized physical memory space 114 of VM 32 according to a page table configured and controlled by guest OS 34. Hypervisor 30, which configures and controls virtualized physical memory 114, then maps the address of page 60b to the address of page 60c within physical memory 14 of host system 10, e.g., using the SLAT mechanism discussed above.

In some embodiments, hypervisor 30 constructs its own virtual memory space 214b that includes a representation of physical memory 14 and utilizes a translation mechanism (e.g., a page table) to map addresses in space 214b to addresses in physical memory 14. In Figure 5, such an exemplary mapping translates the address of page 60c to the address of page 60h. Such mapping allows hypervisor 30 to manage (e.g., read, write, and control access to) memory pages belonging to software objects executing within various VMs running on host system 10.

FIG5 further illustrates a page swap operation performed by guest OS 34. Page swapping is a common feature of modern operating systems, used to efficiently manage available memory resources. In some embodiments, swapping a page out of memory involves the OS moving the contents of the corresponding page from memory to a storage device (e.g., disk) so that the corresponding page can be used to store other data. At a later time, the OS may swap the page in by moving the corresponding content from the storage device back into memory, presumably at an address different from the address of the original page that stored the content. To complete the swap in, the OS may modify the page table entry for the corresponding page to reflect the address change. In the example illustrated in FIG5 , page 60c is swapped out to page 60d on the storage device. Because OS 34 executes within a virtual machine, OS 34 views virtualized physical memory 114 as its physical memory and virtualized storage device 120 as its physical storage device. Therefore, effectively swapping page 60c out of memory involves moving the contents of page 60c to virtualized storage device 120. Device 120 may include an abstraction created by hypervisor 30 of physical device 20, so the contents of page 60d may actually be redirected to page 60k on device 20. In some embodiments, hypervisor 30 may give guest VM 32 direct access to storage device 20, for example, using VT-d technology from [ 15 ]. In such a configuration, virtualized storage device 120 may be consistent with the actual physical storage device of host system 10. To perform the swap-in, OS 34 may move the contents of page 60d to page 60e of virtualized physical memory 114. Guest OS 34 may further modify the page table entry corresponding to page 60a to indicate the address translation from page 60a to page 60e (dashed arrow in FIG. 5 ). Page 60e may be mapped to page 60m in physical memory 14.

FIG6 illustrates an exemplary sequence of steps performed by memory introspection engine 40 to protect a virtual machine from malware, according to some embodiments of the present invention. Such anti-malware protection includes, for example, identifying pages (hereinafter referred to as target pages) of the memory space of a selected process (hereinafter referred to as a target process) executing within the corresponding VM; and protecting the corresponding page contents from unauthorized modification by, for example, a malware entity. In another example, introspection engine 40 may determine whether the target page contains malicious code. The target process may belong to, for example, an application (such as applications 42e-f) or to guest OS 34 in FIG4. When the target process executes under user-level processor privileges (for example, user mode in ), the contents of the target page may not be constantly present in memory but may be occasionally swapped in and out of memory by the OS. By executing outside VM 32, memory introspection engine 40 may not be able to directly access the contents of such swapped-out memory pages.

In the sequence of steps 302-304, engine 40 waits until the current execution context is that of the target process, that is, until the currently executing instruction belongs to the target process. Determining the current execution context may include, for example, reading the contents of the CR3 register of the virtual processor of the corresponding VM (the CR3 register on the x86 platform stores the address of the page structure, which uniquely identifies each executing process). When the execution context is that of the target process, in the sequence of steps 306-308, engine 40 may determine whether the contents of the target page are currently swapped out of memory. If the contents of the target page are in memory, in step 316, engine 40 may continue to introspect the target page (for example, to analyze and/or protect the contents of the target page). If the contents of the target page are currently swapped out, in step 310, engine 40 directly injects a page fault into the corresponding VM to force the target page to be swapped in (as described in detail below). Next, in a sequence of steps 312 to 314 , the engine 40 waits until the target page is swapped in, ie, until the corresponding page content is mapped to the virtualized physical memory of the corresponding VM, to perform introspection.

To determine whether the target page exists in memory (steps 306-308), and to determine whether the target page has been swapped in (steps 312-314), memory introspection engine 40 may access the contents of a page table built by OS 34. In some embodiments, a field (e.g., a dedicated bit) of the page table entry for the target page indicates whether the corresponding page currently exists in memory.

FIG7 illustrates an exemplary sequence of steps performed by engine 40 to directly inject a page fault, thereby forcing a swap in of a target page (step 310 in FIG6 ). In steps 322 through 324, engine 40 evaluates the current state or virtual processor 112 to determine whether a page fault exception can be safely injected into VM 32. Step 322 may include evaluating the priority of the currently processing interrupt request. In Microsoft systems, such evaluation may include, for example, determining the current interrupt request level (IRQL) by looking up the contents of VM 32's segment registers. Exemplary registers include the FS and/or GS registers of the x86 processor architecture, which store pointers to data structures containing IRQLs. In an exemplary embodiment, injecting a page fault is considered safe when IRQL < 2. When a higher priority interrupt is pending (e.g., IRQL ≥ 2), steps 322 through 324 wait for the higher priority request to be serviced.

In some embodiments, step 322 may include determining the privilege level (ring) at which the virtual processor 112 is currently executing. In a host system running Microsoft, when the processor is executing in user mode (ring 3), the IRQL is zero, and injection of such page faults corresponding to user mode pages may be considered safe. When the processor 112 is executing in kernel mode (ring 0), additional determinations may be required to infer whether fault injection is safe.

The sequence of steps 326 through 328 injects a page fault exception into VM 32, which is configured to trigger the swapping of the target page. In an exemplary embodiment, in step 326, engine 40 writes the virtual address of the target page into the CR2 register of the virtual processor of the corresponding VM, thereby indicating to OS 34 which virtual page to swap into memory. Next, in step 328, engine 40 triggers an exception within virtualization processor 112, for example, by writing a set of control bits to the virtual machine control structure (VMCS) of VM 32. The corresponding control bits are configurable to trigger a page fault within the corresponding VM. On processors configured to support virtualization, such control bits are part of the VM entry event injection field of the VMCS.

A VM control structure is a special type of data structure maintained by the hypervisor 30 to describe a guest VM executing on the host system 10. The format of a VMCS can be implementation-specific and/or platform-specific. For a VM that includes multiple virtualized processors 112, the hypervisor 30 can maintain a distinct VMCS for each virtual processor. In some embodiments, each VMCS may include a guest state area that stores data, such as the CPU state and/or the contents of the corresponding virtual processor's control registers, and a host state area that stores similar data for the hypervisor 30. In some embodiments, the processor 12 associates a region in memory with each VMCS, designated a VMCS region. Software can use the region's address (e.g., a VMCS pointer) to refer to a specific VMCS. At any given time, at most one VMCS can be loaded on the processor 12, representing the VM currently controlling the processor.

Figures 8 and 9 illustrate exemplary applications of some embodiments of the present invention within an environment. Figure 8 illustrates a sequence of steps performed by engine 40 to determine the virtual memory address of the target process's primary executable. In step 332, engine 40 may detect the start of the target process. Step 332 may utilize any method known in the art, such as intercepting an OS mechanism that manages a list of active processes. For example, in Windows, whenever a process is created, an indicator of the corresponding process is inserted into the list of active processes; the indicator is removed from the list after the corresponding process ends. In some embodiments, after starting a process, OS 34 also constructs a process-specific data structure (referred to as a process environment block (PEB)) containing data used by OS 34 to manage resources associated with the corresponding process. By intercepting (e.g., placing an intercept) the OS instruction for inserting the target process into the list of active processes, engine 40 may obtain information such as the memory address of the corresponding PEB, which engine 40 may extract in step 334. In Windows, the virtual address of the PEB is stored in an OS data structure referred to as the executing process block (EPROCESS). FIG10 shows an illustrative diagram of such a process-specific data structure.

As a user-level data structure, the virtual memory page containing the PEB data may or may not currently be present in memory. In step 336, the engine 40 determines whether the corresponding virtual memory page is swapped out. If not, the engine 40 proceeds to determine the virtual address of the target process's primary executable, for example, by parsing the PEB data, in step 340. When the PEB data is currently swapped out of memory, step 338 forces the corresponding page containing the PEB data to be swapped in, for example, using the mechanism described above with respect to FIG. 7 .

FIG9 shows an exemplary sequence of steps implemented by engine 40 to perform memory introspection of an executable module (e.g., a library) loaded by a target process. Malware often uses DLLs as a vector for carrying malicious code, so analyzing the contents of such libraries can be important for anti-malware operations. After accessing the virtual page containing PEB data in step 342 (see, for example, steps 336 through 338 above), engine 40 identifies the target module (e.g., a dynamic link library (DLL)) used by the target process and determines whether the corresponding module is loaded in a sequence of steps 344 through 346 through 348. If the target module is loaded, engine 40 may determine the virtual address of the corresponding module in step 350, for example, based on specific data fields in the PEB (see, for example, FIG10). In step 352, engine 40 determines whether the virtual page containing the module data and located at the address determined in step 350 is currently swapped out of memory. If not, engine 40 continues to perform memory introspection of the corresponding module in step 356. When the virtual page of the corresponding module is currently swapped out, in step 354 the engine 40 forces the corresponding virtual page to be swapped in using, for example, the mechanism described above with respect to FIG. 7 .

FIG10 illustrates an exemplary determination of a virtual address within an environment. In some embodiments, OS 34 maintains kernel virtual memory space 214d, wherein a page at virtual address 60p contains a portion of an EPROCESS structure used by OS 34 to manage the execution of a target process. Address 60p can be determined, for example, by intercepting the start of the target process (see, for example, step 332 in FIG8 ). Fields of the EPROCESS data structure hold an indicator (e.g., a pointer) to the process environment block (PEB) of the target process. The pointer indicates a virtual address 60q within process virtual memory 214e assigned by OS 34 to the target process. The PEB structure further includes a pointer to a structure (LDR data) containing information about executable modules (e.g., libraries) loaded by the target process. The LDR data is located at address 60r within space 214e. By traversing the hierarchy of process management data structures constructed by OS 34, introspection engine 40 can thus determine multiple virtual addresses for objects targeted for introspection. When the contents of a memory page located at such an address are swapped out of RAM, engine 40 may force OS 34 to swap in the corresponding page using the methods described herein.

The exemplary systems and methods described above allow for the use of virtualization technology to protect host systems from malware. In some embodiments, a memory introspection engine operates beneath a virtual machine executing on the host system. The memory introspection engine can protect the virtual machine by analyzing the contents of memory pages used by processes executing within the corresponding virtual machine. The introspection engine can thus determine, from outside the corresponding VM, whether the code of the corresponding process contains malware.

In some embodiments, the introspection engine can also prevent unauthorized modification (e.g., by malware) of some critical objects, such as certain drivers and page tables, among others. To protect such objects, some embodiments can prevent changes by intercepting attempts to write to memory pages allocated to the corresponding objects. Such interception can be performed based on the level of the hypervisor.

In conventional anti-malware systems, security applications execute at a processor privilege level similar to that of the operating system or common applications. Such systems may be vulnerable to advanced malware that also operates at the operating system's privilege level. In contrast, in some embodiments of the present invention, the hypervisor executes at the highest privilege level (for example, root mode or ring-1), thereby transferring the operating system to a virtual machine. The memory introspection engine may execute at the same processor privilege level as the hypervisor. Anti-malware operations may therefore be performed at a processor privilege level that is higher than that of the operating system. In some embodiments, a single memory introspection engine may protect multiple virtual machines executing simultaneously on a corresponding computer system.

Although the memory introspection engine executes outside the virtual machine used to protect the target, the engine can determine the virtual addresses used by software objects running within the protected VM. However, when such virtual addresses point to the contents of a page currently swapped out of memory by the operating system, the memory introspection engine cannot access the corresponding contents. In some embodiments of the present invention, when a page is currently swapped out, the memory introspection engine can force the OS to swap in the corresponding page, thereby making the corresponding page contents available for analysis and/or protection. To force the swap in, the memory introspection engine can trigger a processor event (such as a page fault exception) within the virtualization processor of the corresponding virtual machine, which is configured to cause the operating system to bring the swapped out page back to memory. Triggering the processor event may include, for example, writing a set of control bits to a virtual machine control structure used by the corresponding virtual machine. The memory introspection engine can therefore inject a page fault into the corresponding virtual machine without assistance from the OS or from other software executing within the corresponding VM.

It will be apparent to those skilled in the art that the above embodiments can be modified in many ways without departing from the scope of the invention. Therefore, the scope of the invention should be determined by the following claims and their legal equivalents.

Claims (23)

1. A host system for protecting a computer system from malware, the host system including a hardware processor configured to operate: A hypervisor configured to expose a virtual machine including a virtualization processor and virtualization memory, the virtual machine being configured to execute a target process using the virtualization processor, wherein exposing the virtual machine includes a configuration data structure for storing the current state of the virtualization processor, the data structure including an event injection field that, when set to a predetermined value, causes the virtualization processor to generate a page fault; and a memory introspection engine executed outside the virtual machine and configured to: The virtual machine's page table is used to determine whether the target page of the target process's virtual memory space has been swapped out of the virtualized memory; and In response, when the target page is swapped out of the virtualization memory, a page fault is directly injected into the virtual machine. The page fault causes the operating system of the virtual machine to map the target page to a page in the virtualization memory. Directly injecting the page fault includes the memory introspection engine writing the predetermined value into the event injection field. 2. The host system according to claim 1, wherein directly injecting the page fault includes: the memory introspection engine writing the virtual address of the target page into the register of the virtualization processor. 3. The host system of claim 1, wherein the memory introspection engine is further configured to: In preparation for directly injecting the page fault, it is determined whether the injection conditions are met based on the current state of the virtualization processor; and In response, the page error is injected directly when the injection conditions are met. 4. The host system of claim 3, wherein determining whether the event injection condition is met includes: determining the interrupt request level (IRQL) of the virtualization processor. 5. The host system of claim 3, wherein determining whether the event injection condition is met includes: determining the permission level under which the virtualization processor is currently executing. 6. The host system of claim 3, wherein determining whether the event injection condition is met includes: determining the current execution context of the virtualization processor. 7. The host system of claim 3, wherein, in response to determining whether the injection condition is met, the memory introspection engine is further configured to delay injecting the page fault until the injection condition is met if the injection condition is not met. 8. The host system of claim 1, wherein the memory introspection engine is further configured to respond to direct injection of the page fault to: Detect modifications to the page table items of the target page; and In response, it is determined whether the target page is mapped to the page in the virtualized memory based on the modification. 9. The host system of claim 1, wherein the memory introspection engine is further configured to determine whether the target process is malicious based on the content of the target page. 10. The host system of claim 1, wherein the memory introspection engine is further configured to intercept attempts to modify the content of the target page. 11. The host system of claim 1, wherein the memory introspection engine is further configured to prepare for determining whether the target page is to be swapped out of the virtualization memory: Detecting events on the virtualization processor, the events indicating the start of the target process within the virtual machine; and In response, the virtual address of the target page is determined based on the event. 12. A method for protecting a computer system from malware, comprising: A hypervisor is executed using at least one hardware processor of a host system. The hypervisor is configured to expose a virtual machine including a virtualization processor and virtualization memory. The virtual machine is configured to execute a target process using the virtualization processor. Exposing the virtual machine includes a configuration data structure to store the current state of the virtualization processor. The data structure includes an event injection field that, when set to a predetermined value, causes the virtualization processor to generate a page fault. The at least one hardware processor is used to determine whether a target page in the virtual memory space of the target process has been swapped out of the virtualized memory; and In response, when the page is swapped out of the virtualized memory, the page fault is directly injected into the virtual machine using the at least one hardware processor. The page fault causes the operating system of the virtual machine to map the target page to a page in the virtualized memory. Directly injecting the page fault includes the memory introspection engine writing the predetermined value into the event injection field. 13. The method of claim 12, wherein directly injecting the page fault comprises: writing the virtual address of the target page into a register of the virtualization processor. 14. The method of claim 12, further comprising preparing for direct injection of the page error: The at least one hardware processor is used to determine whether the injection condition is met based on the current state of the virtualization processor; and In response, when the injection conditions are met, the page error is directly injected using the at least one hardware processor. 15. The method of claim 14, wherein determining whether the event injection condition is met comprises: determining the current interrupt request level (IRQL) of the virtualization processor. 16. The method of claim 14, wherein determining whether the event injection condition is met comprises: determining the permission level under which the virtualization processor is currently executing. 17. The method of claim 14, wherein determining whether the event injection condition is met comprises: determining the current execution context of the virtualization processor. 18. The method of claim 14, further comprising, in response to determining whether the injection condition is met, delaying the injection of the page error until the injection condition is met when the injection condition is not met. 19. The method of claim 12, further comprising, in response to directly injecting the page error: The modification of page table items of the target page is detected using the at least one hardware processor; and In response, the at least one hardware processor is used to determine, based on the modification, whether the target page is mapped to the page in the virtualized memory. 20. The method of claim 12, further comprising using the at least one hardware processor to determine whether the target process is malicious based on the content of the target page. 21. The method of claim 12, further comprising using the at least one hardware processor to intercept attempts to modify the content of the target page. 22. The method of claim 12, further comprising preparing for determining whether the target page has been swapped out of the virtualization memory: The virtualization processor is detected using the at least one hardware processor, the event indicating the start of the target process within the virtual machine; and In response, the at least one hardware processor is used to determine the virtual address of the target page based on the event. 23. A non-transitory computer-readable medium for protecting a computer system from malware, the non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a host system, cause the host system to form a memory introspection engine, wherein the host system executes a hypervisor that exposes a virtual machine including a virtualization processor and virtualization memory, the virtual machine being configured to execute a target process using the virtualization processor, wherein exposing the virtual machine includes a configuration data structure for storing the current state of the virtualization processor, the data structure including an event injection field that, when the event injection field is set to a predetermined value, causes the virtualization processor to generate a page fault, wherein the memory introspection engine executes outside the virtual machine, and wherein the memory introspection engine is configured to: The virtual machine's page table is used to determine whether the target page of the target process's virtual memory space has been swapped out of the virtualized memory; and In response, when the target page is swapped out of the virtualization memory, a page fault is directly injected into the virtual machine. The page fault causes the operating system of the virtual machine to map the target page to a page in the virtualization memory. Directly injecting the page fault includes the memory introspection engine writing the predetermined value into the event injection field.