Safe hyper-threading for virtual machines

A hypervisor detects a VM exit issued by a first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU, and determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. The hypervisor determines the execution state of the second virtual processor. Responsive to determining that the execution state of the second virtual processor indicates that the second virtual processor is running, the hypervisor sends a first instruction to the second logical processor to cause the second virtual processor to return control to the hypervisor. Responsive to determining that the execution state of the second virtual processor indicates that the second virtual processor has returned control to the hypervisor, the hypervisor executes a hypervisor task using the first logical processor.

TECHNICAL FIELD

The present disclosure is generally related to computer systems, and more particularly, to hyper-thread management in virtualized computer systems.

BACKGROUND

A virtual machine (VM) is an emulation of a computer system. When executed on appropriate hardware, a VM creates an environment allowing the virtualization of an actual physical computer system (e.g., a server, a mainframe computer, etc.). The actual physical computer system is typically referred to as a “host machine.” Typically, a component on the host machine known as a “hypervisor” (or a “virtual machine monitor”) manages the execution of one or more virtual machines or “guests”, providing a variety of functions such as virtualizing and allocating resources, context switching among virtual machines, etc. The operating system (OS) of the virtual machine is typically referred to as the “guest operating system” or “guest OS.” In some implementations, the guest OS and applications executing within the guest OS can be collectively referred to as the “guest.”

A virtual machine may comprise one or more “virtual processors” (VCPUs), each of which maps, possibly in a many-to-one fashion, to a central processing unit (CPU) of the host machine. The hypervisor can manage these mappings in a transparent fashion, thereby enabling the guest operating system and applications executing on the virtual machine to interact with the virtual processors as though they were actual physical entities.

DETAILED DESCRIPTION

Described herein are methods and systems for safe hyper-threading for virtual machines. Hyper-threading technology allows the sharing of CPU resources by presenting multiple logical processors (or threads) as part of a single physical processor. This allows the logical processors to execute simultaneously on the single physical core in different security domains and privilege modes. In virtualized systems, hyper-threading technology can be implemented such that one thread can be executing in hypervisor mode while another is executing code within a virtual machine (e.g., as a virtual processor). Similarly, two threads of a single physical processor can be assigned to execute code simultaneously within two different virtual machines. Hyper-threading, however, can expose systems to significant security risks since logical processors share CPU resources, allowing the leaking of information between software components running on different threads on the same CPU. Thus, it may be possible for sensitive data stored in cache by one thread to be accessible to another thread on the same physical processor.

Some conventional systems mitigate this risk by incorporating scheduling logic in the hypervisor that acts as a gatekeeper for scheduling virtual processors of virtual machines. In such implementations, only virtual processors of the same virtual machine may run on threads of the same host CPU, preventing information from leaking between two different virtual machines. This solution, however, still presents a security risk since one thread can still be executing code from a virtual machine while another thread may be executing hypervisor code. Thus, in some situations, the virtual machine could still gain access to sensitive data accessible to the hypervisor. Other conventional systems mitigate this risk by disabling hyper-threading completely. This solution, however, significantly reduces the performance of the CPU.

Aspects of the present disclosure address the above noted and other deficiencies by implementing safe hyper-threading for virtual machines (VMs). The hypervisor can be configured to detect and trap VM exits initiated by a virtual processor of a virtual machine that executes on a thread of a hyper-threaded CPU. A VM exit refers to a transfer of control from a virtual machine to the hypervisor. The hypervisor can then configure the execution state of any other virtual processors from the same virtual machine to prevent the simultaneous execution of the hypervisor and virtual machine code on threads (logical processors) of the same CPU. Once the hypervisor has completed a task, it can signal virtual processors on the same CPU that it is safe to resume execution.

Aspects of the present disclosure present significant advantages over conventional solutions to the data leakage issues noted above. First, since virtual machine code can be prevented from executing while the hypervisor is simultaneously executing on the same CPU, sensitive information accessible to the hypervisor can be blocked from leaking to virtual machines running on the same CPU. Moreover, by preventing the hypervisor and virtual machine from running simultaneously on the same CPU, the performance benefits of hyper-threading can be retained, rather than being disabled completely. Thus, thread performance can be retained while simultaneously minimizing security risk of leaks. Moreover, managing hyper-threading in this way can significantly improve on-going security of virtualized systems. Unauthorized intrusion attacks can be prevented without knowing the specific details of the attack method since the hypervisor and virtual machine should not execute simultaneously.

FIG. 1depicts a high-level component diagram of an illustrative example of a computer system100, in accordance with one or more aspects of the present disclosure. Other architectures for computer system100are possible, and implementation of a computer system utilizing examples of the present disclosure is not limited to the specific architecture depicted byFIG. 1.

As shown inFIG. 1, the computer system100is connected to a network150and comprises one or more central processing units (CPU)160, main memory170, which may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory) and/or other types of memory devices, a storage device180(e.g., one or more magnetic hard disk drives, a Peripheral Component Interconnect [PCI] solid state drive, a Redundant Array of Independent Disks [RAID] system, a network attached storage [NAS] array, etc.), and one or more devices190(e.g., a Peripheral Component Interconnect [PCI] device, network interface controller (NIC), a video card, an I/O device, etc.). In certain implementations, main memory170may be non-uniform access (NUMA), such that memory access time depends on the memory location relative to CPU160. It should be noted that although, for simplicity, a single CPU160, storage device180, and device190are depicted inFIG. 1, other implementations of computer system100may comprise a plurality of CPUs, storage devices, and devices.

CPU160may be configured to support hyper-threading by permitting logical processors161-A,161-B to execute simultaneously on the single physical core of CPU160. It should be noted that although, for simplicity, two logical processors161have been depicted inFIG. 1, in other implementations, CPU160may comprise more than two logical processors161.

The computer system100may be a server, a mainframe, a workstation, a personal computer (PC), a mobile phone, a palm-sized computing device, etc. The network150may be a private network (e.g., a local area network (LAN), a wide area network (WAN), intranet, etc.) or a public network (e.g., the Internet).

Computer system100may additionally comprise a virtual machine (VM)130. VM130may be an application environment that executes programs as though it was an actual physical machine. VM130may comprise a guest operating system (OS)135, and virtual processors131-A and131-B. Guest OS135may handle the execution of applications within the virtual machine. Virtual processors131-A and131-B may be used by guest OS135to handle the execution of applications, as well as for guest OS functions within the virtual machine. It should be noted that although, for simplicity, a single VM130is depicted inFIG. 1, computer system100may host a plurality of VMs130.

Periodically, virtual machine code (e.g., a guest OS, an application executing within the VM, etc.) may return control to the hypervisor. This may occur as a result of an input/output (I/O) request (e.g., data read, data write, attempt to access an IO device190, etc.), the attempt to execute a privileged instruction, an attempt to access a privileged or protected area of memory that generates a memory page fault, cause the virtual processor to enter an idle state (e.g., via a VM HALT instruction), or the like. In such situations, a virtual machine exit (VM exit) may be triggered that initiates a transfer of execution control of a logical processor161to hypervisor125from the virtual processor131of VM130. Hypervisor125can then determine the cause of the VM exit and process it (e.g., process the I/O request, handle the page fault, assign the logical processor to another task, etc.). Once the VM exit has been handled, hypervisor125can resume execution of the VM by executing an instruction to re-enter the VM (e.g., a “VM enter”).

Each virtual processor131is a component that emulates a physical processor, and that maps to one of central processing units (CPU)160, possibly in a many-to-one fashion. In some implementations, each virtual processor131may map to one of logical processors161of CPU160. For example, virtual processor131-A may map to logical processor161-A, and virtual processor131-B may map to logical processor161-B. Alternatively virtual processor131-A may map to one of logical processors161-A or161-B, while virtual processor161-B may map to a logical processor of another CPU (not pictured). It should be noted that the number of virtual processors may or may not be the same as the number of CPUs or logical processors. In some implementations, hypervisor125manages these mappings in a transparent fashion, so that guest OS135and applications executing on virtual machine130interact with virtual processors131as though they were actual physical processors.

Computer system100may also include a host operating system (OS)120, which may comprise software, hardware, or both, that manages the hardware resources of the computer system and that provides functions such as inter-process communication, scheduling, virtual memory management, and so forth. In some examples, host operating system120also comprises a hypervisor125, which provides a virtual operating platform for virtual machine (VM)130and that manages its execution. It should be noted that in some other examples, hypervisor125may be external to host OS120, rather than embedded within host OS120.

Hypervisor125can include a hyper-thread manager140that implements safe hyper-threading for virtual machines. Hyper-thread manager140can detect and trap exits initiated by a virtual processor131of VM130that executes on a logical processor161(a thread) of a hyper-threaded CPU160. Hyper-thread manager140can then configure the execution state of any other virtual processor131of VM130to prevent the simultaneous execution of the hypervisor125and virtual machine code (e.g., code executing using one of virtual processors131of VM130) on logical processors161of the same CPU160. Once the hypervisor has completed a task, hyper-thread manager140can signal logical processors161on the CPU160that it is safe to resume execution of any suspended virtual processors131.

In an illustrative example, hyper-thread manager140can detect a VM exit issued by virtual processor131-A of VM130, where virtual processor131-A is associated with logical processor161-A of CPU160(e.g., executed by a thread of a hyperthreaded CPU). The VM exit may thus transfer execution control of logical processor161-A to hypervisor125. Hyper-thread manager140can then determine whether virtual processor131-B of VM130is associated with logical processor161-B of CPU160(e.g., another thread of the same CPU). If so, hyper-thread manager140can then determine the execution state of virtual processor131-B and take action to ensure that virtual processor131-B and hypervisor125are not simultaneously executing using logical processor161-A and logical processor161-B respectively. Hyper-thread manager140is described in further detail below with respect toFIG. 2.

FIG. 2depicts a block diagram illustrating an example a hyper-thread manager240for facilitating safe hyper-threading for virtual machines. In some implementations, hyper-thread manager240may correspond to hyper-thread manager140ofFIG. 1. As shown inFIG. 2, hyper-thread manager240may be a component of a computing apparatus200that includes a processing device201, operatively coupled to a memory205, to execute a hypervisor235. In some implementations guest hypervisor235may correspond to hypervisor125ofFIG. 1. In some implementations, processing device201and memory205may correspond to processing device502and main memory504respectively as described below with respect toFIG. 5.

Hyper-thread manager240may include exit processing module241, virtual processor management module242, logical processor management module243, and interrupt processing module244. Alternatively, the functionality of one or more of exit processing module241, virtual processor management module242, logical processor management module243, and interrupt processing module244may be combined into a single module or divided into multiple sub-modules.

Exit processing module241is responsible for detecting VM exits issued by virtual processors231-A,231-B of VM230. As noted above, a VM exit may be triggered when virtual machine code returns execution control of a logical processor to hypervisor235. This may occur as a result of an I/O request (e.g., data read, data write, attempt to access an I/O device190, etc.), the attempt to execute a privileged instruction, an attempt to access a privileged or protected area of memory that generates a memory page fault, cause the virtual processor to enter an idle state (e.g., via a VM HALT instruction), or the like. For example, VM code may be executing using virtual processor231-A, which is associated with logical processor202-A of processing device201(e.g., a thread of the CPU). The VM code may conduct an I/O operation that triggers a VM Exit that transfers execution control of logical processor202-A to hypervisor235. Similarly, the VM code may determine that virtual processor231-A may not have any work to complete, and should therefore enter an idle state. In such instances, a VM exit may be issued via a HALT instruction that places virtual processor231-A in the idle state, and transfers execution control of logical processor202-A to hypervisor235to be assigned to another task.

In some implementations, exit processing module241may determine the type of VM Exit issued by virtual processor231-A, and manage the execution of virtual processor231-B (and any other virtual processors for VM230assigned to logical processors on processing device201) differently based on the type of VM Exit. For example, if virtual processor231-A issues a VM exit with the expectation that execution control of logical processor202-A should be returned to the VM (e.g., and I/O request, page fault, etc.), logical processor202-B (associated with virtual processor231-B) may be immediately halted while the hypervisor235retains execution control of logical processor202-A. Thus, virtual processor231-B should be prevented from executing simultaneously with the hypervisor235. This process is described below with respect toFIG. 3.

Virtual processor management module242is responsible for management of virtual processors231-A and231-B of VM230within the system200. Once a VM exit has been detected and its type determined, hyper-thread manager240may then invoke virtual processor management module242to determine whether any additional virtual processors231are associated with logical processors202of the same processing device201. For example, if virtual processor231-A of VM230issues a VM exit to transfer execution control of logical processor202-A, virtual processor management module242may determine that virtual processor231-B of VM230is associated with logical processor202-B (e.g., a second thread of the same of processing device201). This determination may be made by accessing a data structure managed by the hypervisor235that maintains all known virtual processors, their corresponding execution state, and any logical processors to which they have been given execution control.

Virtual processor management module242may then determine the execution state of any additional virtual processors231that have been given execution control of a logical processor on the same CPU as the virtual processor that issued a VM exit. This determination may be made by accessing a data structure that maintains the execution state of all virtual processors managed by the hypervisor. Continuing with the example noted above, when exit processing module241detects a VM exit issued by virtual processor231-A, virtual processor management module242may then determine the execution state of virtual processor231-B.

As noted above, different actions may be taken based on the determined execution state(s) of any additional virtual processors with execution control of logical processors on the same CPU. Thus, if virtual processor231-B has an execution state that indicates it is running, virtual processor management module242may take action to halt logical processor202-B in order to suspend virtual processor231-B. Alternatively, if virtual processor231-B has an execution state that indicates it has already been halted (e.g., a VM HALT has been issued because virtual processor231-B is idle), virtual processor management module242may take action to transfer execution control of logical processor202-A to hypervisor235to execute a hypervisor task. In this latter case, logical processor202-B may also be utilized to execute a different hypervisor task, may be utilized for another task not related to VM230, or may remain in a halted state until the hypervisor task has completed.

Logical processor management module243is responsible for management of logical processors202-A and202-B of processing device201. In some implementations, logical processor management module243can be invoked to complete the transfer of execution control of a logical processor202from a virtual processor231of VM230to hypervisor235. Logical processor management module243can also be invoked to return execution control of a logical processor202to a virtual processor231once a hypervisor task has been completed.

In an illustrative example, virtual processor231-A issues a VM exit to transfer execution control of logical processor202-A to hypervisor235. Responsive to virtual processor management module242determining that the execution state of virtual processor231-B indicates that it is running, logical processor management module243may be invoked to send an instruction to logical processor202-B (the logical processor associated with virtual processor231-B) to cause the virtual processor202-B to return control to hypervisor235. In some implementations, logical processor management module243may send an inter-processor interrupt (IPI) to logical processor202-B by invoking interrupt processing module244. The IPI can cause logical processor202-B to cause virtual processor231-B to return control to the hypervisor235. Thus, virtual processor231-B should not execute a VM related task while hypervisor235retains execution control of logical processor202-A. Once logical processor202-B has returned control to hypervisor235(e.g., the logical processor has been halted), logical processor management module243can then send an instruction to logical processor202-A to transfer execution control to hypervisor235. In some implementations, logical processor management module243may determine that logical processor202-B has returned control to hypervisor235by receiving a notification from logical processor202-B that it has returned control.

Subsequently, once hypervisor235has completed executing its task using logical processor202-A, logical processor management module243may facilitate returning control of logical processors202-A and202-B to their respective VM related tasks. Logical processor management module243may then invoke interrupt processing module244to send an IPI to logical processor202-B to cause virtual processor231-B to re-enter VM230. Similarly, logical processor management module243may also invoke interrupt processing module244to send an IPI to logical processor202-A to cause virtual processor231-A to re-enter VM230.

The above process may be completed differently if virtual processor231-A initially issues a VM exit with the expectation that execution control of logical processor202-A should not be immediately returned to the VM (e.g., a VM HALT), depending on the execution state of virtual processor231-B. For example, if virtual processor231-B is already in a halted state when virtual processor231-A issues a HALT, then this could indicate that execution control should not be returned to the VM230(e.g., either one of virtual processors231-A or231-B) for either logical processor202. As such, both logical processors202-A and202-B can be assigned to execute other tasks that are not related to VM230. For example, logical processors202-A and202-B may be used for hypervisor tasks. Alternatively, both logical processors could be assigned to execute tasks for virtual processors of a different VM (not pictured). If, on the other hand, virtual processor231-B is executing when virtual processor231-A issues a HALT of logical processor202-A, then virtual processor231-B may remain executing while logical processor202-A is halted. Thus, hypervisor235should be prevented from executing simultaneously with virtual processor231-B. Safe hyper-threading for virtual machines based on detecting a VM HALT is described below with respect toFIG. 4.

As noted above, if exit processing module241determines that virtual processor231-A issued a HALT, virtual processor management module242may be invoked to determine whether VM230has an additional virtual processor231-B that is associated with another logical processor on the same CPU (e.g., logical processor202-B). Virtual processor management module242may then determine the execution state of virtual processor231-B. If virtual processor management module242determines that the execution state of the virtual processor231-B indicates that it is already halted, logical processor management module243may be invoked to send an instruction to the logical processor202-B to cause it to execute a task that is not associated with the VM230(e.g., a task for another VM). Similarly, logical processor management module243may also be invoked to send an instruction to logical processor202-A to cause it to also execute a task that is not associated with the VM230(e.g., a task for another VM).

If, on the other hand, virtual processor management module242determines that (at the time virtual processor231-B executed the HALT) the execution state of the virtual processor231-B indicates that it is running, logical processor management module243may be invoked to send an instruction only to logical processor202-A to HALT logical processor202-A. As noted above, this instruction could be an IPI instruction. Alternatively, logical processor management module243may set an indicator that prevents the hypervisor from executing a hypervisor related task using logical processor202-A. In some implementations, this indicator may be stored in a register, data structure, memory space, or other similar structure, that is checked by hypervisor235prior to executing a hypervisor related task.

Subsequently, logical processor management module243may detect that logical processor202-A is available execute the virtual processor231-A (e.g., it is available to re-enter the VM230). This may occur once any scheduled hypervisor tasks or other tasks not related VM230have completed and returned control to the hypervisor. At this time, logical processor management module243checks the execution state of logical processor202-B (or any other logical processors on the same CPU as logical processor202-A). If logical processor202-A is halted, logical processor management module243can invoke interrupt processing module244to send an IPI instruction to logical processor202-A to cause it re-enter VM230(e.g., by returning execution control to virtual processor231-A). Thus, logical processor202-B can execute VM code without conflict, since logical processor202-A not executing a hypervisor task. If, on the other hand, logical processor202-B is executing a hypervisor task, logical processor management module243can invoke interrupt processing module244to send an IPI instruction to logical processor202-A to HALT logical processor202-A. Thus, logical processor202-A will not simultaneously execute VM code while logical processor202-B is still executing a hypervisor task.

FIG. 3depicts a flow diagram of an example method300for safe hyper-threading for virtual machines based on VM Exits. The method may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), computer readable instructions (run on a general purpose computer system or a dedicated machine), or a combination of both. In an illustrative example, method300may be performed by hyper-thread manager140of hypervisor125inFIG. 1, or hyper-thread manager240of hypervisor235inFIG. 2. Alternatively, some or all of method300might be performed by another module or machine. It should be noted that blocks depicted inFIG. 3could be performed simultaneously or in a different order than that depicted.

At block305, processing logic detects a VM exit issued by first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU. At block310, processing logic determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. At block315, processing logic determines an execution state of the second virtual processor. In some implementations, processing logic makes this determination by receiving a notification from the second virtual processor that the second virtual processor has executed a VM exit to return control to the hypervisor. At block320, processing logic determines whether the execution state of the second virtual processor indicates that it is running. If so, processing proceeds to block325. If so, processing continues to block325. Otherwise, processing proceeds to block335.

At block325, processing logic sends a first instruction to the second logical processor to cause the second virtual processor to return control to the hypervisor. In some implementations, the first instruction is an inter-processor interrupt instruction. At block330, processing logic determines whether the execution state of the second virtual processor indicates that the second virtual processor has returned control to the hypervisor. If so, processing proceeds to block335. Otherwise, processing returns to block330. At block335, processing logic executes a hypervisor task using the first logical processor. After block335, the method ofFIG. 3terminates.

FIG. 4depicts a flow diagram of an example method400for safe hyper-threading for virtual machines based on VM HALTs. The method may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), computer readable instructions (run on a general purpose computer system or a dedicated machine), or a combination of both. In an illustrative example, method400may be performed by hyper-thread manager140of hypervisor125inFIG. 1, or hyper-thread manager240of hypervisor235inFIG. 2. Alternatively, some or all of method400might be performed by another module or machine. It should be noted that blocks depicted inFIG. 4could be performed simultaneously or in a different order than that depicted.

At block405, processing logic detects a VM exit issued by first virtual processor of a virtual machine, where the first virtual processor is associated with a first logical processor of a host CPU. At block410, processing logic determines that the VM exit issued by the first virtual processor is a request to HALT the first virtual processor (e.g., a VM HALT instruction). At block415, processing logic determines that a second virtual processor of the virtual machine is associated with a second logical processor of the host CPU. At block420, processing logic determines an execution state of the second virtual processor.

At block425, processing logic determines whether the execution state of the second virtual processor indicates that the second virtual processor is halted. If so, processing logic continues to block430. At block430, processing logic sends a first instruction to the second logical processor to cause the second logical processor to execute a first task not associated with the virtual machine. In some implementations, this instruction may be an IPI instruction. In some implementations, the first task may be a hypervisor related task or a scheduling task associated with a virtual processor of another virtual machine.

At block435, processing logic a second instruction to the first logical processor to cause the first logical processor to execute a second task not associated with the virtual machine. In some implementations, this instruction may be an IPI instruction. In some implementations, the second task may be a hypervisor related task or a scheduling task associated with a virtual processor of another virtual machine. After block435, the method ofFIG. 4terminates

If, at block425, processing logic determines that the execution state of the second virtual processor indicates that the second virtual processor is running, processing proceeds to block440. At block440, processing logic sends an instruction to the first logical processor to halt the first logical processor. In some implementations, this instruction may be an IPI instruction. In some implementations, processing logic may halt the first logical processor by setting an indicator in a memory space that prevents the hypervisor from executing a hypervisor related task using the first logical processor. After block440, the method ofFIG. 4terminates.

FIG. 5depicts an example computer system500which can perform any one or more of the methods described herein. In one example, computer system500may correspond to computer system100ofFIG. 1. The computer system may be connected (e.g., networked) to other computer systems in a LAN, an intranet, an extranet, or the Internet. The computer system may operate in the capacity of a server in a client-server network environment. The computer system may be a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any device capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device. Further, while a single computer system is illustrated, the term “computer” shall also be taken to include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

The exemplary computer system500includes a processing device502, a main memory504(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory506(e.g., flash memory, static random access memory (SRAM)), and a data storage device516, which communicate with each other via a bus508.

The computer system500may further include a network interface device522. The computer system500also may include a video display unit510(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device512(e.g., a keyboard), a cursor control device514(e.g., a mouse), and a signal generation device520(e.g., a speaker). In one illustrative example, the video display unit510, the alphanumeric input device512, and the cursor control device514may be combined into a single component or device (e.g., an LCD touch screen).

The data storage device516may include a non-transitory computer-readable medium524on which may store instructions526that include hyper-thread manager528(e.g., corresponding to the methods ofFIGS. 3-4, etc.) embodying any one or more of the methodologies or functions described herein. Hyper-thread manager528may also reside, completely or at least partially, within the main memory504and/or within the processing device502during execution thereof by the computer system500, the main memory504and the processing device502also constituting computer-readable media. Hyper-thread manager528may further be transmitted or received over a network via the network interface device522.

Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “detecting,” “determining,” “sending,” “executing,” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Aspects of the disclosure presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the specified method steps. The structure for a variety of these systems will appear as set forth in the description below. In addition, aspects of the present disclosure are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.