Endpoint incident response from a secure enclave through dynamic insertion of an interrupt

A method of protecting an endpoint against a security threat detected at the endpoint, wherein the endpoint includes, in memory pages of the endpoint, an operating system (OS), a separate software entity, and remediation code, includes the steps of: transferring control of virtual CPUs (vCPUs) of the endpoint from the OS to the separate software entity; and while the separate software entity controls the vCPUs, storing, in an interrupt dispatch table, an instruction address corresponding to an interrupt, wherein the remediation code is stored at the instruction address, and replacing a next instruction to be executed by the OS, with an interrupt instruction, wherein the interrupt is raised when the OS executes the interrupt instruction, and the remediation code is executed as a result of handling of the interrupt that is raised.

BACKGROUND

There exists a wide array of solutions for responding to malware attacks, such attacks involving unauthorized actions being performed on a victim's computer system. Some incident-response (IR) solutions offer cloud-based response capabilities in which administrators remotely communicate with agents that are running in the computer system. Using a simulated shell environment with a command-line interface (CLI), administrators isolate infected computers by stopping their network activity except for that between the agents and the administrators. Additionally, through the CLI, administrators remediate threats by terminating malicious processes.

However, responding to such incidents remotely may not provide protection in certain cases. First, sophisticated malware has been developed that hijacks the agents' activities including the networking activities thereof, which prevents the administrators from transmitting a response to the agents altogether. Second, even if the administrators are able to transmit a response, some malware tracks commands that the agents execute. By tracking these commands, such malware learns the remediation behavior to make future attacks more difficult to neutralize. Third, establishing a network connection between agents and the cloud in order to transmit the response may take a long time. During that time, the malware may be able to complete its unauthorized activities and destroy any evidence. A solution that can be used for isolating a computer system and responding to incidents and that is impervious to the above-mentioned behaviors of sophisticated malware is needed.

SUMMARY

Accordingly, one or more embodiments provide a method of protecting an endpoint against a security threat detected at the endpoint, wherein the endpoint includes, in memory pages of the endpoint, an operating system (OS), a separate software entity, and remediation code. The method includes the steps of: transferring control of virtual CPUs (vCPUs) of the endpoint from the OS to the separate software entity; and while the separate software entity controls the vCPUs, storing, in an interrupt dispatch table, an instruction address corresponding to an interrupt, wherein the remediation code is stored at the instruction address, and replacing a next instruction to be executed by the OS, with an interrupt instruction, wherein the interrupt is raised when the OS executes the interrupt instruction, and the remediation code is executed as a result of handling of the interrupt that is raised.

DETAILED DESCRIPTION

Techniques for protecting an endpoint, e.g., a VM, in response to a security attack are described. The techniques involve utilizing a “guest monitor,” which is a software entity of the VM that can access memory pages allocated to the VM. Like an agent running inside the VM, the guest monitor may be utilized to provide cloud-based IR. However, unlike the agent, when the VM is launched, the guest monitor is loaded into a portion of VM memory that is inaccessible to an OS of the VM. As such, the guest monitor can execute remediation-related commands from a secure enclave of the VM that is inaccessible to malware executing inside the VM. Such malware thus cannot prevent a cloud-based server from transmitting a response to the guest monitor and cannot observe the guest monitor's behavior. Furthermore, for even faster IR, a local security appliance instead of the cloud-based server may transmit a response to the guest monitor.

Whenever the guest monitor is “awakened,” control over vCPUs of the VM are transferred from the OS to the guest monitor, which effectively “freezes” the OS and any malware executing in the VM. The VM is thus isolated whenever its guest monitor is awakened. While the VM is isolated, the guest monitor creates an interrupt service routine, the handling of which involves executing remediation code. Furthermore, the guest monitor causes the OS to raise an interrupt corresponding to the new interrupt service routine as the next instruction for the OS to execute when control of the vCPUs is returned to the OS. Accordingly, the OS has no opportunity to run any malicious code before raising and handling the interrupt to neutralize the security threat. These and further aspects of the invention are discussed below with respect to the drawings.

FIG.1is a block diagram of a virtualized computer system100in which embodiments may be implemented. Virtualized computer system100includes a cluster of hosts110, a security appliance180, and a virtualization manager182executing in a data center102, and an IR server190executing remotely. Data center102may be an on-premise data center that is controlled and administrated by a particular enterprise or business organization. Data center102may also be a cloud data center that is operated by a cloud computing service provider. IR server190is administrated from outside data center102to remotely respond to incidents (e.g., security threats) in hosts110. AlthoughFIG.1depicts a single datacenter with hosts executing therein, other embodiments utilize a hybrid model including both an on-premise datacenter and a cloud datacenter. In such a hybrid model, the on-premise datacenter includes hosts executing therein, and the cloud datacenter includes a cloud management platform that controls software executing on the hosts of the on-premise data center.

Each of hosts110is a server constructed on a server grade hardware platform170such as an x86 architecture platform. Hardware platform170includes conventional components of a computing device, such as one or more central processing units (CPUs)172, system memory174such as random-access memory (RAM), local storage176such as one or more magnetic drives or solid-state drives (SSDs), and one or more network interface cards (NICs)178. CPU(s)172are configured to execute instructions such as executable instructions that perform one or more operations described herein, such executable instructions being stored in system memory174. Local storage176of hosts110may optionally be aggregated and provisioned as a virtual storage area network (vSAN). NIC(s)178enable hosts110to communicate with each other and with other devices over a physical network104.

Each hardware platform170supports a software platform112. Software platform112includes a hypervisor140, which is a virtualization software layer that abstracts hardware resources of hardware platform170for concurrently running VMs such as VMs120and130. One example of a hypervisor140that may be used is a VMware ESX® hypervisor, available from VMware, Inc. Although the disclosure is described with reference to VMs, the teachings herein also apply to other types of virtual computing instances such as containers, Docker® containers, data compute nodes, isolated user space instances, and the like that may be attacked by malware and that may be remediated according to embodiments.

VMs120and130execute processes122and132, which are respectively supported by guest OSs124and134. Each guest OS includes a process list126or136, which is a data structure such as a linked list capturing information about processes running in the respective VMs. For example, process lists126and136may include the names and memory usage of running processes along with those of any threads executing therein. Each guest OS further includes interrupt dispatch tables127or137. Interrupt dispatch tables127and137are data structures that are used to determine how to handle interrupts raised by VMs120and130, respectively.

Each guest OS further includes a guest agent128or138for collecting information about the respective guest OSs such as memory offsets of respective process lists. Guest agents128and138are configured to directly communicate with IR server190to allow for remote monitoring, isolation, and remediation of VMs120and130. On the other hand, according to embodiments, to thwart sophisticated malware, guest agents128and138are also configured to share information with guest monitors146and154, respectively, including the memory offsets of the respective process lists. Specifically, each guest agent shares the information with a hypervisor kernel160, which forwards the information to the respective guest monitors. Guest monitors146and154and hypervisor kernel160are discussed further below.

Hypervisor140includes virtual machine monitors (VMMs)142and150, hypervisor kernel160, and a security module164. VMMs142and150implement the virtual system support needed to coordinate operations between hypervisor140and VMs120and130, respectively. Each VMM manages a virtual hardware platform for a corresponding VM. Such a virtual hardware platform includes emulated hardware such as vCPUs144or152and guest physical memory. Each VMM further includes nested page tables (not shown) for translating virtual addresses of a corresponding VM to physical addresses of system memory174.

Each of interrupt dispatch tables127corresponds to one of vCPUs144, and each of interrupt dispatch tables137corresponds to one of vCPUs152. Whenever an interrupt is raised on one of vCPUs144, the corresponding one of interrupt dispatch tables127is used to determine how to handle the interrupt on the vCPU. Similarly, whenever an interrupt is raised on one of vCPUs152, the corresponding one of interrupt dispatch tables137is used to determine how to handle the interrupt on the vCPU. Each VMM further includes guest monitor146or154for its respective VM.

Guest monitors146and154are software entities that reside in the memory spaces of VMs120and130, respectively. However, guest monitors146and154specifically reside in memory pages that are made inaccessible to guest OSs124and134, i.e., in secure enclaves of VMs120and130. Resultingly, guest monitors146and154can access all the memory pages allocated to VMs120and130, respectively. However, all other processes of VMs120and130can only access a subset of such pages, i.e., the pages that are allocated to VMs120and130minus the pages in which guest monitors146and154reside. Although embodiments are described with respect to guest monitors146and154, in other embodiments, other components including hypervisor kernel160may instead be used to monitor VMs120and130and provide IR to threats therein.

Hypervisor kernel160provides OS functionalities such as file system, process creation and control, and process threads. Hypervisor kernel160also provides scheduling of CPU(s)172and system memory174across VMs120and130, VMMs142and150, and security module164. Hypervisor kernel160includes timers162, one for guest OS124and guest monitor146and another for guest OS134and guest monitor154. When one of timers162expires, hypervisor kernel160“freezes” the corresponding guest OS by saving a state of the guest OS from registers of the corresponding VM's vCPUs and transferring control of the vCPUs to the corresponding guest monitor. The guest monitor can then execute commands (if any have been provided to the guest monitor). After the guest monitor executes its commands (if any), hypervisor kernel160repopulates the registers of the VM's vCPUs with their saved state, transfers control of the vCPUs back to the guest OS, and restarts timer162.

It should be noted that hypervisor kernel160also transfers control of the vCPUs in other situations. For example, hypervisor140may install “write traces” on various memory pages allocated to VMs120and130, specifically in locations that guest OSs124and134are not expected to write to. The installation of write tracing is further described in U.S. patent application Ser. No. 17/002,233, filed Aug. 25, 2020, the entire contents of which are incorporated herein by reference. When one of guest OSs124and134writes to a traced location, hypervisor140is notified, which is referred to as a “trace fire.” Alternative to write tracing, VMMs142and150may set “read-only” flags in respective nested page tables to track the locations that guest OSs124and134are not expected to write to. When one of guest OSs124and134attempts to write to a read-only page, a fault is triggered, and a fault handler notifies hypervisor140of the attempted write. In response to a trace fire or to such a fault, hypervisor kernel160saves the state of the responsible guest OS from registers of the associated VM's vCPUs and transfers control of the vCPUs to the respective guest monitor.

It should be noted that because guest OSs124and134are unaware of the presence of guest monitors146and154, hypervisor kernel160only briefly takes control of vCPUs away from a guest OS. For example, the total time during which hypervisor kernel160takes control away from the guest OS may be approximately equal to the amount of time it takes for the corresponding guest monitor to transmit a packet to security appliance180plus the amount of time it takes for security appliance180to transmit a packet back to the guest monitor. As such, vCPUs144and152always appear to be “alive” from the perspective of guest OSs124and134despite brief intervals of apparent vCPU inactivity. When control is transferred from a guest monitor back to a guest OS, the vCPUs appear to the guest OS to be functioning normally such that it is unnecessary for the guest OS to execute any recovery mechanisms.

Security module164connects to guest monitors146and154and to security appliance180. Security module164thus acts as a bridge between guest monitor146and security appliance180and between guest monitor154and security appliance180. Security appliance180may be a computer program that resides and executes in a central server of data center102or a VM executing in one of hosts110. For local IR, VMs of hosts110can be remediated directly from security appliance180. Otherwise, security appliance180further connects to IR server190, thus acting as a bridge between security module164of each of hosts110and IR server190. IR server190is a cloud-controlled server through which an administrator monitors and remediates VMs of hosts110from outside data center102.

Virtualization manager182communicates with hosts110via a management network (not shown) provisioned from network104to perform administrative tasks such as managing hosts110, provisioning and managing VMs120and130, migrating VMs from one of hosts110to another, and load balancing between hosts110. Virtualization manager182may be a computer program that resides and executes in a central server of data center102or a VM executing in one of hosts110. One example of virtualization manager182is VMware vCenter Server,® available from VMware, Inc.

Gateway184provides VMs120and130, security appliance180, and other devices in data center102with connectivity to an external network, e.g., the Internet. Communication between devices in data center102and IR server190are thus facilitated by gateway184. Gateway184manages public internet protocol (IP) addresses for VMs120and130and security appliance180and routes traffic incoming to and outgoing from data center102. Gateway184may also provide networking services such as firewalls, network address translation (NAT), dynamic host configuration protocol (DHCP), load balancing, and virtual private network (VPN) connectivity over the external network. Gateway184may be a computer program that resides and executes in a central server of data center102or a VM executing in one of hosts110.

FIG.2Ais a system diagram illustrating an example of memory pages accessible to guest OS124of VM120after a security threat is detected at VM120. In the example ofFIG.2A, guest OS124is supporting four processes A, B, C, and D, process D being malicious. As such, system memory174includes the code of each process, and process list126lists each of the processes. The memory space of VM120further includes any other memory pages202that are accessible to guest OS124, which may include memory traces in locations that guest OS124is not expected to write to and which may be set as read-only.

FIG.2Bis a system diagram illustrating an example of remotely transmitting commands to guest monitor146to neutralize the security threat detected at VM120. First, IR server190transmits the commands to security appliance180. Such transmission may be executed by the administrator of IR server190, or such transmission may be executed automatically by IR server190in response to the security threat. Next, security appliance180forwards the commands to security module164in hypervisor140. Finally, security module164forwards the commands to guest monitor146to be executed the next time control of vCPUs144is transferred from guest OS124to guest monitor146. The commands executed by guest monitor146include storing remediation code in memory pages accessible to guest OS124and causing guest OS124to raise an interrupt and execute the remediation code to terminate the malicious process and neutralize the security threat. It should be noted that for faster IR response, commands may be provided directly from security appliance180without IR server190.

FIG.2Cis a system diagram illustrating an example of storing an interrupt instruction204, remediation code208, and an instruction address210in memory pages202accessible to guest OS124to cause guest OS124to raise an interrupt and remediate VM120. As illustrated, guest monitor146stores interrupt instruction204in a memory page202-1, which when executed by guest OS124, causes guest OS124to raise the interrupt. Specifically, guest monitor146stores interrupt instruction204to further cause guest OS124to execute interrupt instruction204immediately upon control of vCPUs144being transferred from guest monitor146to guest OS124. Guest OS124will execute interrupt instruction204as its next instruction instead of an original next instruction206in a memory page202-2. Original next instruction206is the next instruction guest OS124was going to execute before guest OS124was frozen.

Guest monitor146also stores remediation code208in a memory page202-3, which when executed by guest OS124, remediates VM120, e.g., by deleting the code of malicious process D. Guest monitor146also stores instruction address210in an interrupt dispatch table127-1, which corresponds to one of vCPUs144and is stored in a memory page202-4. Instruction address210is an address of remediation code208and is thus used by guest OS124to locate remediation code208to handle the interrupt.

FIG.3Ais a block diagram illustrating instructions executable by guest OS124including interrupt instruction204. Interrupt instruction204, which is illustrated as “Int 25h,” includes an index “25h” (25 hexadecimal). 25h is an index of interrupt dispatch table127-1. When guest OS124executes interrupt instruction204, guest OS124raises an interrupt and handles the interrupt based on instructions stored in interrupt dispatch table127-1at index 25h. Furthermore, it should be noted that interrupt instruction204has been stored in memory as the next instruction for guest OS124to execute. Accordingly, guest OS124has already executed the instruction “mov dword ptr [F8021F878E040010h],eax,” and when guest OS124next has control of vCPUS144, guest OS124will immediately execute “Int 25h.”

FIG.3Bis a block diagram illustrating interrupt dispatch table127-1. In the example ofFIG.3B, interrupt dispatch table127-1includes entries at rows 0h to 25h, i.e., indexes 0h to 25h. Furthermore, at row 25h, guest monitor146has inserted a “jmp” instruction and instruction address210. If guest OS124executes interrupt instruction204, which specifies index (row) 25h, guest OS124executes the “jmp” instruction inserted at row 25h and then executes remediation code208, which is stored at instruction address210.

FIG.3Cis a block diagram illustrating remediation code208for handling the interrupt. Remediation code208includes instructions such as “add” and “xchg” instructions for neutralizing the detected security threat, e.g., by deleting malicious code. Additionally, as a last instruction for guest OS124to execute, remediation code208includes signaling to hypervisor kernel160to again transfer control of vCPUs124to guest monitor146. Control is transferred to guest monitor146at the end of remediation so that guest monitor146can perform various cleanup tasks, as discussed further below in conjunction with7.

FIG.4is a flow diagram of steps of a method400carried out by guest agent128, hypervisor kernel160, and guest monitor146to initialize guest monitor146to wait for an event to begin a remediation process, according to an embodiment. At step402, VM120begins booting, and as VM120boots, guest agent128determines the memory offsets of memory pages at which guest OS124data structures such as process list126and interrupt dispatch tables127are stored. At step404, guest agent128transmits the memory offsets to hypervisor kernel160.

At step406, hypervisor kernel160detects the memory offsets and forwards the offsets to guest monitor146. Guest monitor146later uses the offsets, e.g., to scan process list126to analyze the state of VM120after a security attack and provide information to IR server190. IR server190uses such information to determine how to respond and transmits commands to guest monitor146, as discussed above in conjunction withFIG.2B. Guest monitor146also later uses such offsets to locate and update interrupt dispatch tables127, according to embodiments.

At step408, hypervisor kernel160starts timer162corresponding to VM120to expire after a specified time interval elapses. The time interval can be predetermined such that it is the same each time hypervisor kernel160starts timer162. The time interval can also be determined at run time. For example, hypervisor kernel160may initially start timer162to expire after one second. Later, a security threat may be detected that requires remediation. After the security threat is remediated and any malicious process(es) are terminated, hypervisor kernel160may reduce the time interval, e.g., to two hundred fifty milliseconds.

At step410, hypervisor kernel160waits for an event that triggers transferring control of vCPUs144from guest OS124to guest monitor146. As discussed earlier, hypervisor kernel160may transfer control in response to timer162elapsing, a trace fire, or a fault. At step412, if such an event has not yet been detected, method400returns to step410, and hypervisor kernel160continues to wait for an event. Otherwise, if such an event has been detected, method400moves to step414, and hypervisor kernel160begins the process of freezing guest OS124. At step414, hypervisor kernel160saves the state of guest OS124from registers of vCPUs144, to system memory174. At step416, hypervisor kernel160transfers control of vCPUs144from guest OS124to guest monitor146, thus preventing guest OS124from scheduling any tasks on vCPUs144. After step416, guest OS124is frozen. By extension, any malware executing in VM120is similarly frozen, and guest OS124cannot schedule any tasks originating from such malware.

At step418, if commands have been provided to guest monitor146to begin a remediation process, guest monitor146begins the remediation process, as discussed further below in conjunction withFIG.5. After step418, method400ends. It should be noted that if no such commands have been provided to guest monitor146, guest monitor146signals to hypervisor kernel160to transfer control of vCPUs144back to guest OS124. Hypervisor kernel160then restores the state of guest OS124to vCPUs144, returns control of vCPUs144to guest OS124, and waits again for an event to transfer control of vCPUs144to guest monitor146.

FIG.5is a flow diagram of steps of a method500carried out by guest monitor146to cause guest OS124to raise an interrupt and handle the interrupt by executing remediation code, according to an embodiment. Method500is carried out upon guest monitor146freezing guest OS124and beginning a remediation process, as described above in conjunction withFIG.4. At step502, guest monitor146writes remediation code to memory pages accessible to guest OS124. Specifically, guest monitor146writes remediation code received from IR server190or directly from security appliance180.

At step504, guest monitor146scans one of interrupt dispatch tables127for an empty row, i.e., a row that does not currently store instructions for handling any interrupts. At step506, if guest monitor146found an empty row, method500moves to step508, and guest monitor146selects the empty row. Otherwise, if guest monitor146did not find an empty row, method500moves to step510. At step510, guest monitor146selects a filled row and copies information therein to another memory page. For example, the information may include instructions for handling a keyboard interrupt.

At step512, guest monitor146stores an instruction address in the row selected at either step508or510. Specifically, guest monitor146stores the address of a memory page at which guest monitor146stored remediation code at step502, i.e., the address corresponding to the interrupt for remediating VM120. At step514, guest monitor146determines the next instruction guest OS124was going to execute before being frozen. To determine the next instruction, guest monitor146checks the program counter register of the one of vCPUs144corresponding to the one of interrupt dispatch tables127. The program counter register stores the address of the next instruction to execute.

At step516, guest monitor146replaces the next instruction for guest OS124to execute with an interrupt instruction. It should be noted that guest monitor146first copies the original next instruction for guest OS124to execute, to another memory page. The interrupt instruction includes the row number of the one of interrupt dispatch tables127. At step518, guest monitor146transmits a notification to hypervisor kernel160to transfer control of vCPUs144to guest OS124. Hypervisor kernel160then restores the state of guest OS124to vCPUs144and returns control of vCPUs144to guest OS124.

At step520, guest monitor146waits until control of vCPUs144is transferred back to guest monitor146. Control of vCPUs144is transferred back after guest OS124raises an interrupt and executes the remediation code written at step502, as discussed further below in conjunction withFIG.6. The last instruction of the remediation code is to signal hypervisor kernel160via a notification to transfer control of vCPUs144back to guest monitor146. At step522, after hypervisor kernel160has saved the state of guest OS124from registers of vCPUs144, to system memory174, and hypervisor kernel160has transferred control of vCPUs144to guest monitor146, guest monitor146begins cleanup of the memory pages accessible to guest OS124. Such cleanup is discussed further below in conjunction withFIG.7. After step522, method500ends.

FIG.6is a flow diagram of steps of a method600carried out by guest OS124to handle an interrupt by executing remediation code, according to an embodiment. Method600is performed after guest monitor146returns control of vCPUs144to guest OS124. At step602, guest OS124checks the program counter register of the one of vCPUs144on which an interrupt instruction is stored. At step604, guest OS124executes the instruction at the address stored by the program counter, which is the interrupt instruction. Execution of the interrupt instruction causes guest OS124to raise an interrupt.

At step606, guest OS124accesses the one of interrupt dispatch tables127corresponding to the one of vCPUs144. At a row specified by the interrupt instruction, guest OS124reads an instruction address of remediation code to execute. At step608, guest OS124handles the interrupt by executing the remediation code at the instruction address to neutralize the security threat, e.g., by deleting code of a malicious process. As the last instruction of the remediation code, guest OS124transmits a notification to hypervisor kernel160to transfer control of vCPUs144to guest monitor146to begin cleanup, as discussed further below in conjunction withFIG.7. Hypervisor kernel160then saves the state of guest OS124from registers of vCPUs144, to system memory174, and hypervisor kernel160transfers control of vCPUs144from guest OS124to guest monitor146. After step608, method600ends.

FIG.7is a flow diagram of steps of a method700carried out by guest monitor146to clean up the memory pages accessible to guest OS124after guest OS124executes remediation code, according to an embodiment. At step702, guest monitor146deletes the remediation code from the memory pages. At step704, guest monitor146locates the row of the one of interrupt dispatch tables127at which an instruction address of the deleted remediation code is stored, i.e., the address corresponding to an interrupt that guest OS124handled to remediate VM120. Guest monitor146deletes the instruction address from the located row along with any other instructions stored in the located row.

At step706, if applicable, guest monitor146copies information previously removed from the located row, back to the row. For example, the removed information may include instructions for handling a keyboard interrupt. At step708, guest monitor146locates the interrupt instruction for raising the interrupt, in the memory pages accessible to guest OS124. Guest monitor146replaces the interrupt instruction with a previously replaced next instruction to be executed by guest OS124. At step710, guest monitor146transmits a notification to hypervisor kernel160to again return control of vCPUs144to guest OS124. Hypervisor kernel160then restores the state of guest OS124to vCPUs144and returns control of vCPUs144to guest OS124. After step710, method700ends.

The embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities. Usually, though not necessarily, these quantities are electrical or magnetic signals that can be stored, transferred, combined, compared, or otherwise manipulated. Such manipulations are often referred to in terms such as producing, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments may be useful machine operations.

One or more embodiments of the invention also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for required purposes, or the apparatus may be a general-purpose computer selectively activated or configured by a computer program stored in the computer. Various general-purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations. The embodiments described herein may also be practiced with computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, etc.

One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in computer-readable media. The term computer-readable medium refers to any data storage device that can store data that can thereafter be input into a computer system. Computer-readable media may be based on any existing or subsequently developed technology that embodies computer programs in a manner that enables a computer to read the programs. Examples of computer-readable media are hard disk drives (HDDs), SSDs, network-attached storage (NAS) systems, read-only memory (ROM), RAM, compact disks (CDs), digital versatile disks (DVDs), magnetic tapes, and other optical and non-optical data storage devices. A computer-readable medium can also be distributed over a network-coupled computer system so that computer-readable code is stored and executed in a distributed fashion.

Virtualized systems in accordance with the various embodiments may be implemented as hosted embodiments, non-hosted embodiments, or as embodiments that blur distinctions between the two. Furthermore, various virtualization operations may be wholly or partially implemented in hardware. For example, a hardware implementation may employ a look-up table for modification of storage access requests to secure non-disk data. Many variations, additions, and improvements are possible, regardless of the degree of virtualization. The virtualization software can therefore include components of a host, console, or guest operating system (OS) that perform virtualization functions.

Boundaries between components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the invention. In general, structures and functionalities presented as separate components in exemplary configurations may be implemented as a combined component. Similarly, structures and functionalities presented as a single component may be implemented as separate components. These and other variations, additions, and improvements may fall within the scope of the appended claims.