System and method for security and privacy aware virtual machine checkpointing

Abstract

A checkpointing method for creating a file representing a restorable state of a virtual machine in a computing system, comprising identifying processes executing within the virtual machine that may store confidential data, and marking memory pages and files that potentially contain data stored by the identified processes; or providing an application programming interface for marking memory regions and files within the virtual machine that contain confidential data stored by processes; and creating a checkpoint file, by capturing memory pages and files representing a current state of the computing system, which excludes information from all of the marked memory pages and files.

Description

FIELD OF THE INVENTION

The present technology relates to the field of virtual machine security, and in particular security of checkpoint information stored in physical persistent memory.

BACKGROUND OF THE INVENTION

Virtualization technology is being widely adopted in grid and cloud computing platforms [31, 34, 23, 28] to improve server consolidation and reduce operating costs. On one hand, virtual machines (VMs) help improve security through greater isolation and more transparent malware analysis and intrusion detection [22, 24, 27, 10, 11, 14, 17, 29, 26, 19]. On the other hand, virtualization also gives rise to new challenges in maintaining security and privacy in virtualized environments. Although significant advances have been made in developing techniques to secure the execution of VMs, a number of challenges remain unaddressed.

VM checkpointing refers to the act of saving a permanent snapshot (or checkpoint) of a VM's state at an instant in time. Virtual Machine (VM) checkpointing enables a user to capture a snapshot of a running VM on persistent storage. A VM's state includes, at the minimum, its memory image and CPU execution state and possibly additional states such as virtual disk contents. The checkpoint can be later used for various purposes such as restoring the VM to a previous state, recovering a long-running process after a crash, distributing a VM image with a preset execution state among multiple users, archiving a VM's execution record, conducting forensic examination, etc. Most hypervisors such as VMware (VMware Inc.), Hyper-V (Microsoft, Inc.), VirtualBox (Oracle Inc.), KVM [35], and Xen (Xen.org) support VM checkpointing.

Despite the above benefits, VM checkpoints can drastically prolong the lifetime and vulnerability of sensitive information. Checkpoints are stored on persistent storage and contain the VM's physical memory contents at a given time instant. Data that should normally be discarded quickly after processing, such as passwords (especially clear text passwords), credit card numbers, health records, or trade secrets, can now be saved forever in persistent storage through VM checkpointing.

This vulnerability can be demonstrated using a common scenario of entering credit card information in a website. As shown in FIG. 4, the FireFox browser was started inside a VirtualBox VM. The browser was then connected to www.amazon.com, “my account” clicked to add credit card information, the number 9149239648 entered into the credit card number field, and then checkpointing was performed. When searching through the checkpoint file with a hex editor, the credit card number entered earlier was located. In some of experiments, the checkpoint file contains the string “addCreditCard-Number=9149239648”, which can enable an attacker to locate the credit card number easily by searching for the string “CreditCard” in the checkpoint. Furthermore, even if the checkpointing is performed after the browser terminates, the credit card number can still be located in the checkpoint file, likely because the browser's memory was not cleared before the browser terminated. In other words, the common advice to “close your browser after logging out” may give users a false sense of security. Many users are not aware that their input data may still reside in memory even after the application that has processed such data terminates. Such users may mistakenly assume that checkpointing the VM is safe simply because the application has terminated.

Passwords in the memory of xterm terminal emulator (both running and terminated) were also identified in the checkpoint file.

Besides memory, even checkpointing a VM's disk may also end up storing users' confidential data in the snapshot. For example, Balduzzi et. al [36] analyzed 5303 public Amazon EC2 snapshots and found that many of them contain sensitive information such as passwords, browser history, and deleted files.

Previous work on minimizing data lifetime has focused on clearing the deallocated memory (also known as memory scrubbing). Chow et al. [6] and Garfinkel et al. [12] discussed in depth the problem of sensitive data being stored in memory, and observed that the sensitive data may linger in memory for extended periods and hence may be exposed to compromise. In [7], authors proposed a multi-level approach to clearing deallocated memory at the application, compiler, library, and system levels. A similar mechanism is included in Windows operating systems, which uses system idle time to clear deallocated memory pages [30]. Also, in Unix systems, it is common to clear memory before reuse [12]. However, simply clearing deallocated memory does not solve our problem because memory pages that have not been deallocated may contain sensitive information and such information may be checkpointed. As a result, SPARC also clears the memory pages of the excluded processes in checkpoints. Selectively clearing memory pages during checkpointing is much more challenging than scrubbing only deallocated memory because multiple processes may share the same memory pages (e.g. shared libraries) and we must ensure that excluding one process will not affect other processes when the VM is restored.

Garfinkel et al. [12] also proposes to encrypt sensitive information in the memory and clear the sensitive information by simply discarding the key. However, encrypting sensitive information in memory can add significant overheads to access the information and may still expose sensitive information if the VM is checkpointed at the moment when some program decrypts the sensitive information.

Features protecting virtual disk, memory, and checkpoints have found their way into research prototypes as well as commercial virtualization products. Garfinkel et al. [13] developed a hypervisor-based trusted computing platform that uses trusted hardware features such as encrypted disks and the use of a secure counter to protect against file system rollback attacks, to permit systems with varying security requirements to execute side-by-side on the same hardware platform. The platform's privacy features include encrypted disks and the use of a secure counter to protect against file system rollback attacks in which the state of a file is rolled back. [15] and [2] also suggested encrypting checkpoints. However, encrypting the checkpoint alone is insufficient because (1) it still prolongs the lifetime of confidential data that should normally be quickly destroyed after use; (2) when the VM is restored, the checkpoint will be decrypted and loaded into the memory of the VM, thus exposing the confidential data again; (3) the checkpoint file may be shared by multiple users, thus increasing the likelihood of data leakage.

VMware ACE [2], VMware Infrastructure [33], and VirtualBox [25] allow users to exclude the entire memory from being checkpointed. However, none of them provides a level of granularity that we do by selectively excluding processes from the checkpointed memory. Davidoff et al. [9] retrieved clear text passwords from the physical memory of a Linux system. Their work aimed to show that the physical RAM may retain sensitive information even after the system has been powered off, and the attacker with physical access to the system can steal information through cold boot memory dumping attacks. However, with checkpoints, the problem is significantly more severe: in the RAM, the amount of time the sensitive information persists in the memory after the machine is powered off, is limited by the RAM's ability to retain information in absence of power. However, the checkpoints are saved to the disk and the information stored in the checkpoints can persist for long time. Also, they assume that the attacker has physical access to the system, but we do not.

Several prior works have employed VM checkpointing to enable execution replay for intrusion analysis and OS debugging. Dunlap et al. [11] proposed an intrusion detection mechanism called ReVirt which allows instruction-by-instruction replay of the guest OS execution. King et al. [18] used ReVirt and disk logging to implement an OS debugger. However, neither work attempts to address data lifetime issues raised by VM checkpointing.

SUMMARY OF THE INVENTION

To address the limitations of traditional checkpointing technologies, two approaches are provided to prevent users' confidential data from being stored in VM checkpoints. The first is an application-transparent approach for situations when it is not possible to modify the applications that handle confidential data. The approach seeks to identify processes that store confidential data and to exclude all the memory pages and files that potentially contain data accessed by these processes from the checkpoint file. While transparent, this approach results in the termination of applications when the VM is later restored. The second approach is an application-visible approach which preserves the application, but not the confidential data, upon VM restoration. The key idea is to provide the application programmers with an API that allows them to mark the memory regions and files that contain confidential data, and to be notified by the hypervisor when VM checkpointing or restoration events occur. Thus an application can adapt its execution and the visibility of confidential data to checkpoint/restore events. In both approaches, we assume that the VM is not compromised when the checkpointing is performed. A cooperative application may also store a time-varying code along with variable or contingent data, which permits the application to determine whether data is stale or has been restored. This, in turn permits blanking or corruption of the respective data in the checkpoint file, to the extent it is present, without interference with the application, since the application will ignore the contents if the data is restored or stale in any case.

The key challenge with both approaches is to exhaustively exclude or sanitize all VM contents that contain confidential data and to ensure that the VM's stability and consistency are maintained when the VM is restored from the checkpoints. Similar approaches can be used to prevent confidential data from being stored in disk checkpoints or other local, remote or distributed storage media.

Application-Transparent Approach for Excluding Confidential Data

An application-transparent approach is investigated for privacy-aware checkpointing for cases where it is not possible to modify a VM's applications, such as Web browsers, Email clients, Terminals etc.

Since the internal semantics of the application, such as data structures handling confidential information, are not known, the best one can do to exclude confidential information from checkpoints is to exclude the entire memory footprint of the application in both user and kernel space. This approach ensures that, when the VM is later restored from the sanitized checkpoint, the original applications that handled confidential information will no longer resume. Developing an application-transparent approach is challenging because processes and the operating system can have complex dependencies. Specifically, we expect the following requirements to be met in order to safely exclude entire applications from VM checkpoints: (1) During checkpointing, the stability of any processes currently executing in the VM should not be affected; (2) Checkpointing should exhaustively identify and exclude all memory regions accessed by applications that handle confidential information; (3) After restoration, processes that did not have any dependencies (such as inter-process communication) with the excluded application should resume normally; (4) The mechanism should not compromise the security of the VM and the hypervisor.

FIG. 2B gives the high-level architecture of the proposed application-transparent approach, which works with both hosted and native hypervisors. A special process called the guest service inside the VM collects physical addresses of memory pages that belong to the applications being excluded from the VM checkpoint. When checkpointing is initiated, another special process in the hypervisor, called the exclusion service, requests the guest service to provide the collected physical addresses of memory pages to be excluded. The exclusion service then relays the addresses to the checkpointer in the hypervisor, which in turn zeros out the specified pages in the checkpoint file.

Another option is to monitor the user input stream, or more generally selectively from the I/O stream from non-program memory sources during a session. The selection of sources, such as user keyboard input, is such that a reasonable assumption may be applied that any such information contains information that might be private, though exceptions may be provided. The stream is then searched or cross correlated with the checkpoint files, and memory locations that include “copies” of the stream are then tagged as possible private information. In some cases, this will be highly disruptive to a restoration of a checkpoint file, since this may void the state of an application, and therefore is best applied to applications whose particular state is not desired to be restored.

To demonstrate the feasibility of the application-transparent approach, a prototype called SPARC—a Security and Privacy AwaRe Checkpointing system [38] was developed. SPARC ensures that all memory footprint of the excluded process, such as virtual memory pages, TTY buffers, and network packets, are cleared. FIGS. 1A and 1B show an example where a user enters a credit card number into the FireFox web browser and the checkpoint is performed as soon as the credit card number is entered. FIG. 1A gives the screenshot of a VM restored using VirtualBox's default mechanism. FIG. 1B gives the screenshot of the VM restored using SPARC in which Firefox and the information processed by Firefox (such as the credit card number entered) are excluded from being checkpointed. SPARC also handles dynamic changes to virtual-to-physical memory mappings while checkpointing is in progress (since memory pages can be swapped in and out of disks), by freezing all user space processes, except the guest service.

The performance of the SPARC prototype was evaluated on a number of real-world applications. FIGS. 5A and 5B compare the execution time of performing checkpointing and restoration using SPARC and the VirtualBox's default mechanism. All experiments were conducted on a host with Intel Dual CPU 2.26 GHz processor and 2 GB of RAM, and running Ubuntu Linux 10.4 kernel version 2.6.32, and a guest VM with 800 MB of memory, a single processor, and Ubuntu Linux 9.10 kernel version 2.6.31. Each data point is an average of execution time over 5 runs. The experimental results show that the prototype imposes 0:5%-7:1% overhead on checkpointing, 1:4%-2:5% overhead on restoration, and 1%-5:3% overall overhead.

Designing a Process Container to Facilitate Privacy-Aware Checkpointing

The sensitive data processed by a process may reside in a number of memory locations such as process memory, the deallocated pages, TTY buffers, the socket/pipe/FIFO buffers etc. Currently, disparate locations in the VM's kernel memory must be examined in order to identify memory pages related to a process. To ease the identification of process-specific pages, a light-weight process container may be provided that cleanly encapsulates the state of each process (or process groups). Processes running inside the container will be excluded from being checkpointed. The design of such a container also makes traditional techniques for taint analysis easier and more efficient. Existing container mechanisms[20, 37] do not provide adequate support for memory tracking and exclusion for operations such as VM checkpointing.

Accounting for Inter-Process Dependencies

Processes may communicate with each other directly or indirectly through mechanisms such as sockets, pipes, FIFO buffers etc. As a result, excluding a process may affect other processes that communicate with it after restoration. In addition, non-system-critical processes that have interacted with the excluded process may obtain sensitive information from the excluded process, and hence also need to be excluded. Techniques may therefore be provided to account for such inter-process dependencies while maintaining system stability after restoration. All processes that depend upon the excluded process should be exhaustively identified. One possible solution is to monitor the establishment of inter-process dependencies using hooks in the guest kernel and analyze this information to derive inter-process dependencies. This approach, however, may miss some external dependencies that could occur when some the corresponding code paths have not been executed before checkpointing. For example, this approach cannot detect the dependency where the excluded process writes to a file before checkpointing and another process accesses the file after restoration. This issue may be addressed by combining both static analysis and dynamic tracking.

Ensuring Consistent Storage

A process being excluded from checkpoint file may be performing a write operation on a file or a database when checkpointing is performed. If the memory pages are simply cleared of the process from the checkpoints and the process killed during restoration, the file or the database could be left in an inconsistent state after restoration. Privacy-aware checkpointing could compound this problem by introducing I/O operations that do not complete after restoration. One approach to solving this problem is to checkpoint the specific files that have been closed by the process, and after restoration, roll back such files to a prior consistent state. Another approach is to track all the I/O operations on files opened by the excluded process and undo those operations upon VM restoration.

Security Analysis

Potential attacks that may specifically target privacy-aware checkpointing may also be identified. For example, the attacker may use privacy-aware checkpointing to hide their activities by excluding their malicious applications. This can affect intrusion detection techniques that rely on replaying checkpoints (e.g. [11]). Such potential attacks may be identified through formal verification, i.e., formally modeling the system and the attackers' behavior, and checking if the system conforms to desirable security properties.

Application-Visible Approach for Excluding Confidential Data

The application-transparent approach described above for privacy-aware checkpointing is useful when the applications within the VMs cannot be modified. Since the semantics of the application internals are unknown, this approach requires that the application be terminated when the VM is later restored, because the integrity of the application cannot be guaranteed upon resumption from a sanitized checkpoint. However, in some situations it may be desirable to keep the application alive after the VM is restored.

Ideally, one would prefer that the application can determine on its own as to what internal state to reset and what to retain after a VM restoration event. To do so, firstly, an application needs to keep track of all the internal application state that contains confidential data so that it can be excluded from the checkpoint. Secondly, after a VM is restored from a checkpoint, the application needs to be able to resume execution safely, even though some of its internal state (containing confidential data) was excluded from the checkpoint. Finally, some of the application's confidential data may be stored in the guest OS in the form of internal kernel state, such as network packets, I/O buffers etc. Thus a VM checkpointing should ensure that such kernel state is excluded from the checkpoint and that the kernel can resume safely after VM's restoration.

To address the above challenges, an application-visible approach is provided, which preserves the application, but not its confidential data, when a VM is restored from the checkpoint. As the name suggests, the basic idea is to expose the VM checkpointing and restoration operations to the applications within the VM through an application programmer interface (API). The API allows an application to specify the memory regions that contain confidential data before a privacy-aware checkpointing operation occurs and to resume normally with integrity once the VM is restored from a sanitized checkpoint. Specifically, the API will (a) allow applications to register confidential memory, which will not be checkpointed or transmitted without explicit permission of the applications; (b) inform applications just before checkpointing to allow applications to transition to a “safe” state; (c) inform applications after checkpointing completes to allow applications to resume safely; and (d) inform applications after the VM is restored from a checkpoint so that applications can restart safely.

While an application can use the API above to register the memory location of its confidential data, it is still possible that other memory locations that are not registered become tainted by the confidential data during normal processing by the application. Information flow analysis may be performed to automatically register all variables that may store the registered data. In addition, the application also constantly interacts with the guest kernel by invoking system calls and exchanging data for I/O operations. Thus confidential data may also reside in the kernel memory at the time the checkpointing is initiated. Therefore, the checkpointer should exclude the application's footprint that may be present in kernel memory, not just in user space memory.

One approach is as follows. When checkpointing is initiated, the kernel will temporarily pause new system calls and I/O requests from the application and complete (or flush) any pending I/O operations such as disk I/O, network packets, display buffers, etc. The kernel will also zero out all I/O buffers after the completion of the I/O operations to prevent data leakage through buffer reuse. Once the kernel memory is sanitized of application's confidential data, the VM checkpointing operation can be allowed to proceed. Scrubbing the kernel memory in this manner could potentially add non-trivial latency to the start of checkpointing.

The technique permits application programmers to use a privacy-aware checkpointing API, to help applications retain greater control over their confidential data and execution state during VM checkpointing and after VM restoration. Specifically, by making the checkpointing mechanism visible to the applications, leakage of confidential data from the VM can be prevented without compromising the application's stability after the VM is restored. In addition, the technique will enable programmers to exclude confidential data that cannot be specified by users of the application, such as encryption keys processed within the program.

It is therefore an object to provide a security and privacy aware VM checkpointing mechanism, which enables users to selectively exclude processes and terminal applications that contain users' confidential and private information from being checkpointed. The technology helps minimize the lifetime of confidential information by preventing unintended checkpointing of process-specific memory contents. A prototype of the technology using the VirtualBox hypervisor and Linux VM and tested it over a number of applications. This imposes only 1:02%-5:29% of overhead with common application workloads in testing.

The technology can also exclude confidential disk information from being checkpointed. VMs are designed in which the state of each process is cleanly encapsulated. This helps avoid scrubbing process-specific information from disparate locations in OS memory. In addition, process containers can tightly isolate the entire state of a process and hence simplify the task of identifying and destroying sensitive information. Finally, the technology assumes that the hypervisor and the VM have existing runtime protection mechanisms against malicious intrusions and focuses on exclusively selective exclusion of confidential process information from checkpoints. Potential attacks on the technology that may specifically target the technology to hide the attacker's activities, may be identified, and counter-measures developed.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A shows VM restored using VirtualBox's default checkpointing mechanism;

FIG. 1B shows VM restored using SPARC with FireFox excluded;

FIGS. 2A and 2B shows the Architecture of SPARC with an application aware and application transparent approach, respectively;

FIG. 3 shows the Teletype (TTY) subsystem architecture;

FIG. 4 shows a scenario where the credit card number is checkpointed;

FIGS. 5A and 5B show experimental results of SPARC and VirtualBox's default checkpointing mechanism; and

FIG. 6 shows a hardware overview.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present technology provides techniques to address some of the security and privacy issues in VM checkpointing. VM checkpointing saves a persistent snapshot (or a checkpoint) of the entire memory and disk state of a VM in execution.

Security and Privacy AwaRe Checkpointing (SPARC) is a mechanism that enables users to selectively exclude processes and terminal applications that contain sensitive data from being checkpointed. Selective exclusion is performed by the hypervisor by sanitizing those memory pages in the checkpoint file that belong to the excluded applications. SPARC poses only 1.02-5.29% of overhead with common application workloads, if most pages are dirty before checkpointing is performed, in a commodity Linux operating system.

SPARC enables users to exclude specific applications, which contain users' confidential and private information, from being checkpointed by the hypervisor. For example, a user may wish to exclude a web browser application from being checkpointed because the user may enter his password and credit card number using the browser. Moreover, SPARC enables users to exclude terminal applications on which applications processing sensitive information are running from being checkpointed. A SPARC prototype based on the VirtualBox 3.1.2 OSE hypervisor and Ubuntu Linux 9.10 guest (kernel v2.6.31) was implemented.

Excluding an Application from Checkpoint

SPARC enables users to specify applications they wish to exclude from being checkpointed. Such applications are typically applications that may process sensitive information (e.g. FireFox, Internet Explorer, Email clients, etc). VirtualBox checkpointing creates two files: a .sav file which stores the contents of the VM's physical memory, and a .vdi file which stores the disk image. For efficiency, when checkpointing the disk image, instead of cloning the entire disk, VirtualBox freezes the current disk and creates a new differencing disk to which all subsequent write operations are redirected. Exclusion of physical memory of specific applications from being checkpointed is a particular focus. Disk checkpointing issues may be analogously handled.

Again, consider the example where a user has entered a credit card number into the FireFox web browser. If the user performs checkpointing after the credit card number is entered, then the credit card number may be stored in the checkpoint even if FireFox has been terminated or is being used to access other URLs. SPARC would let the user exclude FireFox from being checkpointed, i.e., data processed by FireFox will not be stored in the checkpoints (but the corresponding memory pages will not be cleared from RAM in order not to affect the current execution of processes). FIG. 1A gives the screenshot of a VM restored using VirtualBox's default mechanism, in which checkpointing is performed as soon as the user enters his or her credit card number. FIG. 1B gives the screenshot of the VM restored using SPARC in which FireFox and the information processed by FireFox are excluded from checkpointing.

FIG. 2A gives the high-level architecture of SPARC. First, the user selects a list of applications that he or she wishes to exclude from being checkpointed. Next, a special process called the guest service in the VM invokes custom system calls to identify and collect physical addresses of memory pages that belong to the application being excluded, such as process memory, page cache pages, etc. Custom syscalls were used for ease of prototyping and can be easily replaced with a more transparent and extensible ioctl interface. Checkpointing is initiated from another special process called the host service located at the host system. The host service sends a notification to the guest service that checkpointing has been requested. The guest service replies with the collected physical addresses of memory pages that need to be excluded. The host service then relays the addresses to the hypervisor which in turn commences the checkpoint. The checkpointer in the hypervisor uses the received physical addresses to determine which memory to clear in the say file. To ensure that VM can be restored successfully, excluding a process should not affect other processes. As a result, memory pages that are shared by multiple processes will not be excluded from being checkpointed.

Excluding Process Physical Memory

In the virtual address space of a process in Linux, the program code segment stores the executable code of the program. The uninitialized and initialized data sections store uninitialized and initialized static variables, respectively. The heap contains dynamically allocated memory. The memory-mapped region for shared libraries section contains shared libraries mapped into the memory of the process. The stack contains information about function calls in progress e.g., local variables of functions.

SPARC identifies and collects information about memory pages that belong to a process with ID pid and excludes those pages from the checkpoint. First, the guest service invokes a system call that locates the struct task struct associated with each process, which links together all information of a process e.g. memory, open files, terminal, and pending signals. This structure contains field struct mm struct *mm which points to the structure containing virtual memory information of a process. The mm struct contains fields unsigned long start code and unsigned long end code which point to the beginning and ending addresses of the process' code segment respectively, and struct vm area struct * mmap which points to the head of the list of vm area structs where each vm area struct represents a segment of process virtual memory. The vm area struct contains fields unsigned long vm start and unsigned long vm end which point to the beginning and ending addresses of the segment within the virtual process memory space, struct file * vm file which points to the corresponding file descriptor if the segment represents a memory mapped file (e.g. library or otherwise NULL), and struct vm area struct *vm next which points to the next segment. The system call then traverses a list of vm area structs and compares the vm start and vm end against start code and end code. If they match, then the memory segment represents an executable image, and hence is skipped because it cannot contain sensitive information and clearing the executable image may affect other processes which share the same in-memory executable image. Also, it checks if vm file is NULL and if so adds the address to the list; otherwise, the segment represents a shared library mapped into memory, and is skipped over because it may affect other processes which have mapped the same library into memory.

The process file system (procfs) is a virtual file system that enables access and modification of kernel parameters from the user space through a file-like interface. For example, the user can find out the previously described process virtual memory information by reading file /proc/pid/maps. The guest service converts the virtual address of each page into the physical address based on file /proc/pid/pagemap in the procfs. For each virtual page of the process, this file contains e.g., a 64-bit integer which encodes a bit indicating whether the page is resident in the physical memory and if so the physical address of the page. To avoid affecting other processes in the system, all resident pages which are being mapped more than once are skipped. To determine the number of times a physical page has been mapped, the guest service checks the file /proc/kpagecount which contains an array that records the number of times each physical page has been mapped.

Finally, the physical address of each page is sent to the host service which in turn relays the address to the hypervisor. When VirtualBox creates a memory checkpoint, prior to saving a physical page to the .sav file, SPARC checks if the physical address of the page matches one of the received addresses. If not, it saves the contents of the page to the checkpoint. Otherwise, it saves a page containing all 0's. To implement this behavior in the VirtualBox, the function pgmSavePages( ), which saves the VM's physical memory in checkpoints, was modified.

Because pages are constantly swapped between the disk and the physical memory, the virtual-to-physical memory mappings of a process may change after collecting the physical addresses. This may result in excluding the wrong memory contents. This is overcome by freezing all user space processes except the guest service. This is achieved by using the freeze processes( ) function of the Linux kernel and preventing the guest service from freezing by setting its PF NOFREEZE flag. Once the checkpointing completes, all processes are unfrozen with the thaw processes( ) function, and the execution proceeds as normal. When the VM is restored, the guest service detects the restoration event and sends the SIGKILL signal to each target process whose memory contents were previously excluded during checkpointing. This SIGKILL signal is useful to allow the guest kernel to clean up any residual state (other than memory) for excluded processes before the VM resumes. Finally, the guest service unfreezes the remaining processes and the execution proceeds as normal.

If, prior to the checkpoint, the target process deallocates pages containing sensitive information, these page can no longer be identified and cleared. Hence, the function free pages( ) which deallocates pages is modified, to zero out any page belonging to the target process prior to deallocation.

Excluding Pages of a Process in the Page Cache

Page cache is used by the kernel to speed up disk operations by caching disk data in the main memory. Page cache speeds up disk operations as follows. When data is read from the disk, a page is allocated in the physical memory and is filled with corresponding data from the disk. Thus, all subsequent reads targeted at the same disk location can quickly access the data in the main memory. Subsequent write operations to the disk location simply modify the page in the page cache. The kernel, after some delay, synchronizes the page with the disk. Every disk operation in Linux goes through the page cache (except for the swap device or files opened with O DIRECT flag) [5].

If the process performs disk I/O operations, the sensitive information read from and written to the disk may reside in the page cache. For example, when searching for any string using the Google search engine through a web browser, it was found that the string appears in the kernel's page cache, possibly because Google caches suggestions for frequent searches on the local disk. Moreover, when a process terminates, the page cache retains some of the pages of the terminated process for a period of time in case that the same data is accessed by another process in the near future. Even when the page is evicted, the page contents will remain in the free memory pool until overwritten.

SPARC excludes the cached pages of the target process in the checkpoints as follows. First, it locates the file descriptor table of the target process (struct fdtable * fdt). The file descriptor table contains field struct file ** fd which is an array of opened file descriptors and struct fd set *open fds which points to the structure containing information about open file descriptors. If open fds contains a set bit for file descriptor i, we examine location i in array fd and refer to the field struct* fd entry which points to the directory entry associated with a file descriptor. The directory entry contains a field struct inode* d inode which points to the inode associated with the directory entry. Reference is then made to field struct address space i mapping* of the inode, which contains information about pages in the page cache that cache information of the file represented by the file descriptor. Next, function pagevec lookup( ) is called, which takes as a parameter the i mapping field of the inode and an object of type struct pagevec that contains an array pages of page descriptors. Function pagevec lookup( ) uses the i mapping field of the inode to identify all pages in the page cache which cache the data of the file represented by the file descriptor and fills the pages field of page vec with page descriptors of such pages. The page descriptors are then converted to physical addresses of the pages, the addresses transferred to the host service, and they are cleared similarly to the process physical pages.

Note that when a process closes a file descriptor, the descriptor is removed from the descriptor table of the process. As a result, if the process closes the descriptor prior to checkpointing, the above approach will fail to detect the associated pages in the page cache. To counter this, whenever a file descriptor is closed, all pages are evicted and cleared from the page cache associated with the inode of the closed file descriptor.

Even after a page is being evicted from page cache (remove from page cache( )), the physical memory pages may still retain sensitive data belonging to the target process. Hence SPARC sanitizes (zeros out) each evicted page that was originally brought into the cache on behalf of the target process.

Finally, the (cleared) pages in the page cache may also be used by other processes. To avoid affecting the processes which rely on these pages, when the VM is restored (but before the processes are thawed), all pages used by the target processes are flushed from the page cache.

Excluding Pipe Buffers

Pipes and FIFOs are mechanisms commonly used for implementing producer/consumer relationship between two processes. A pipe enables communication between the parent and the child processes. A parent process creates a pipe by issuing a pipe( ) system call. The system call returns two file descriptors. Any data written the first file descriptor (e.g. via the write( ) system call) can be read from the second descriptor (e.g. with the read( ) system call. Shell programs make use of pipes to connect output of one process to the input of another (e.g. “ls|grep myinfo”). FireFox browser also uses pipes to trace malloc memory allocations.

FIFOs are similar to pipes but allow communication of two unrelated processes. A FIFO is created via mkfifo( ) system call, which takes the name of the FIFO as one of the parameters. Once created, the FIFO appears like a regular file on the file system, but behaves like a pipe: the producer process opens the FIFO “file” for writing and the consumer process for reading. For example, in a terminal, a user can create a FIFO called myfifo with command mkfifo myfifo. Issuing command echo “Data lifetime is important”>myfifo will write the string “Data lifetime is important” to the buffer of myfifo. Subsequent command cat myfifo will remove the string from the buffer of myfifo and print “Data lifetime is important”. FIFOs are frequently used by the Google Chrome to implement communications between the renderer process and the browser process [16].

Data exchanged via pipes and FIFOs flows through a pipe buffer in the kernel. Thus, if the target process makes use of pipes and/or FIFOs, the corresponding pipe buffers should also be sanitized. Each pipe buffer is implemented using a struct pipe buffer structure, which contains a field page pointing to the page descriptor of a page storing the actual inter-process data.

Pipe buffers are sanitized as follows. First the file descriptors opened by the process which represent pipes and FIFOs are located, in a manner similar to identifying file descriptors representing regular files, except that the S ISFIFO macro is called, which takes the i mode field of the inode and returns true if the file descriptor represents a pipe or a FIFO. If the macro returns true, the struct pipe inode info *i pipe field of the inode is referred to. This field contains array struct pipe buffer bufs[PIPE BUFFERS] of all pipe buffers owned by the pipe. The array is then traversed and the physical address of the page associated with each pipe buffer determined.

Excluding Socket Buffers

All application-level network communication takes place through network sockets. With each socket, the kernel associates a list of socket buffers (sk buffs) which contain data exchanged over the socket. If a process sends or receives sensitive information via an open socket (e.g. through read( ) and write( ) system calls), the information may be stored in the sk buffs of the sockets used by the process. Therefore, when excluding a process, all sockets opened by the process are detected the memory associated with sk buffs sanitized.

Identifying all descriptors of a process that represent sockets is similar to detecting pipes and FIFOs, except that the S ISSOCK macro is used. The struct socket *SOCKET I(struct inode *inode) function is used to look up struct socket structure associated with the inode of the socket file descriptor. The socket structure contains the field struct sock *sk, which contains a queue of sending sk buffs called sk write queue and a queue of receiving sk buffs called sk receive queue; both have the type struct sk buff head. These two queues from the sk buff head are then gone through. Each sk buff contains field unsigned char *data which points to the data carried by the sk buff. The contents of the data fields of each sk buff in the checkpoints are cleared, every time when the sk buff is released. For each sk buff in these two queues, virt to phys( ) macro is used to translate the virtual address of the tt sk buff to the corresponding physical address and transfer the address to the host service.

GUI Related Issues

It is common for processes to display sensitive information on the screen. When a VM is restored, but before the target process is terminated, the information displayed by the process may linger on the screen for a brief moment. To address the problem, at checkpointing time, the XCreateWindow( ) API provided by X-Windows is invoked to visually cover the windows of the target processes with black rectangles. When the checkpoint completes, the rectangles are removed and the user continues using the process. When the VM is restored, the windows remain covered. The windows are removed briefly after sending the SIGKILL signals to the target processes and unfreezing the processes. To detect all windows of a given process, the list of all open windows is traversed, and the windows' NET WM PID property—the process ID of the process owning the window, is checked.

SPARC also enables a user to choose the process to exclude from checkpointing by clicking on the process window. When the user clicks the window, SPARC automatically checks the NET WM PID property of the window and the process is then excluded as previously described. To enable this functionality, some code was borrowed from xwininfo[3], xprop [4], and slock[1] utilities.

Note that the buffers belonging to the X-windows, GTK, and other GUI components may also contain sensitive information of the process encoded in a different format. Currently pages in the checkpoints that contain clear text are zeroed out. Zeroing out pages that contain sensitive information with different formats can use a similar approach.

Excluding Terminal Applications

Applications running on terminals may take confidential data as inputs and output confidential data on the terminal. As a result, terminals where the excluded applications are running should also be excluded from being checkpointed.

In Linux, there are two main types of terminals: virtual consoles and pseudo terminals. A system typically contains 7 virtual consoles (named tty1-tty7); the first 6 consoles usually provide a text terminal interface consisting of the login and shell, and the 7th console usually provides a graphical interface. Pseudo terminal applications emulate a text terminal within some other graphical system. A typical pseudo terminal application such as xterm forks off a shell process (e.g. bash). When the user runs a command (e.g. ls), the shell forks off a child process and replaces the child's executable image with the code of the specified command. In all terminal types, by default, the child process inherits the terminal of its parent process. In this paper, we consider two of the most often used terminals: virtual consoles and terminal emulators.

All terminals rely on the Teletype (TTY) subsystem in the kernel. FIG. 3 shows the architecture of the TTY subsystem where arrows indicate the flow of data. The uppermost layer of the TTY subsystem is the TTY core, which arbitrates the flow of data between user space and TTY. The data received by the TTY core is sent to TTY line discipline drivers, which usually convert data to a protocol specific format such as PPP or Bluetooth. Finally, the data is sent to the TTY driver, which converts the data to the hardware specific format and sends it to the hardware. There are three types of TTY drivers: console, serial port, and pseudo terminal (pty). All data received by the TTY driver from the hardware flows back up to the line disciplines and finally to the TTY core where it can be retrieved from the user space. Sometimes the TTY core and the TTY driver communicate directly [8].

Identifying Terminals where a Processes is Running

The terminal on which a process is running is identified as follows. First, the list of task structs associated with the process and refer to the field struct signal struct *signal which points to the structure containing signal related information of the process is traversed. The struct signal struct contains field struct tty struct *tty, which links together all information related to an instance of TTY subsystem. The tty struct contains field char name[64] which stores the name of the terminal where process P is running. If the process is running on the virtual console, then the name is “ttyxx” where “xx” is a number. Otherwise, if the process is running on a pseudo terminal, then the name is “ptsxx”.

Once the terminal name where the process is running is determined, all other processes which are running on the same terminal are identified. Such processes will also be excluded from being checkpointed because the corresponding terminal is excluded. This is achieved by traversing the list of task structs and checking if the signal→tty→name field matches that of the tty struct of a target process. If so, the process is excluded.

If the process is running on a pseudo terminal, the pseudo terminal application (e.g. xterm) is also excluded because it may contain the input or output information of the process. The terminal application is usually not attached to the same terminal as the target process. However, the terminal application can be detected by following the task struct * real parent pointer which points to the task struct of a parent process, until the terminal application is reached. The terminal application and all its descendants are then excluded as described above.

Excluding TTY Information

An instance of the TTY subsystem associated with the console/pseudo terminal is sanitized by clearing the buffers at every level shown in FIG. 3. The tty struct representing the TTY subsystem contains all such buffers.

When excluding a virtual console, the associated tty struct is located as follows. Array vc cons of type struct vc is traversed. This structure contains a field struct vc data * d which points to the structure containing console related information including int vc num which represents the console number. If vc num matches the number of the excluded console, then the field tty struct * vc tty which points to the tty struct associated with the console is referred to.

Next, the information stored in the relevant tty structs is used to find all buffers associated with the TTY subsystem. The TTY core uses structure tty buffer to buffer the information received from the user space. The buffer includes field char buf ptr which points to the character buffer and field size which stores the size of the buffer. The tty struct contains field buf, which contains pointers to lists of all tty buffers associated with the TTY core. TTY line discipline drivers use three buffers: read buf, write buf, and echo buf. read buf stores the data received from the TTY driver, write buf stores the data received from the TTY core, which needs to be written to the TTY device, and echo buf stores the characters received from the device which need to be echoed back to the device. In experiments, no information buffered in the console driver was found. Next the physical addresses of the aforementioned buffers are obtained and send the addresses along with buffer sizes to the host service.

Excluding TTY subsystems of pseudo terminals is slightly more complex because the pseudo terminal driver (also known as pty) must be sanitized. The pseudo terminal driver is a specialized interprocess communication channel consisting of two cooperating virtual character devices: pseudo terminal master (ptm) and pseudo terminal slave (pts). Data written to the ptm is readable from the pts and vice-versa. Therefore, in a terminal emulator, a parent process can open the ptm end of the pty and control the I/O of its child processes that use the pts end as their terminal device i.e. stdin, stdout, and stderr streams. Both pts and ptm devices are associated with tty struct structure. The pts tty struct can be located by examining the field signal→tty→name of the task struct associated with children processes of the pseudo terminal application e.g. the bash shell process forked by xterm. The tty struct * link field of the pts tty struct points to the tty struct of the ptm device. The buffers of both tty structs must be cleared. The rest of the operations are similar to operations involved in excluding a virtual console.

Sensitive data may persist in the TTY subsystem buffers even after they are deallocated. Hence, to prevent such data from being checkpointed we modify functions: buffer free( ) and tty buffer free all( ) to sanitize the tty buffers on deallocation, static inline ssize t do tty write( ) and void free tty struct( ) to sanitize write buf and echo buf, and n tty close( ) to sanitize the read buf.

Experiments

The following experiments were performed.

First an xterm terminal application was run, a string entered into the xterm prompt and, the VM checkpointed. The string appeared in the .sav file 6 times. After clearing the memory of xterm and its child process bash, the string appeared in the .sav file 3 times. After zeroing out xterm, bash, and the associated TTY buffers, the string no longer appeared in the file.

In the second experiment, xterm was used to run the “su” program which is used to gain root privileges, the password entered into the su's prompt, and a checkpoint created. The string appeared twice. Clearing xterm, bash, and su processes had no effect on the number of appearances. Once we cleared the TTY buffers the string disappeared.

Performance Results

The performance of SPARC was evaluated on a number of applications that may process sensitive information: FireFox web browser, ThunderBird email client, Evince document viewer, Gedit text editor, OpenOffice Writer word processor, Skype VOIP application, Gnote desktop notes software, and Xterm terminal emulator. All experiments were conducted on a host system with Intel Dual CPU 2.26 GHz processor and 2 GB of RAM, and running Ubuntu Linux 10.4 kernel version 2.6.32, and a guest VM with 800 MB of memory, a single processor, and Ubuntu Linux 9.10 kernel version 2.6.31.

TABLE 1
Execution time for performing checkpointing
using VirtualBox's checkpointing mechanism.
	Execution Time (seconds)
					Open
Operations	Firefox	Thunderbird	Evince	Gedit	Office	Skype	Gnote	Xterm
Checkpointing	16.13	16.38	16.91	16.65	15.76	16.59	17.18	17.40
Restoration	10.45	12.18	13.02	9.91	10.49	10.30	9.97	12.05

TABLE 2
Execution time for performing checkpointing using SPARC.
	Execution Time (seconds)
						Open
	Operations	Firefox	Thunderbird	Evince	Gedit	Office	Skype	Gnote	Xterm
1	Receive checkpoint	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
	notification from host
2	Identify processes	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.03
	running on a terminal
3	Freeze all user	0.01	0.01	0.01	0.01	0.01	0.01	0.01	0.01
	processes
4	Get physical page	0.11	0.10	0.10	0.10	0.08	0.08	0.09	0.14
	addresses of the
	process
5	Get page cache pages	0.04	0.03	0.04	0.05	0.03	0.04	0.03	0.06
	of the process
6	Get physical addresses	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.06
	of TTY buffers
7	Get physical addresses	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
	of pipe buffers
8	Get physical addresses	0.02	0.03	0.02	0.02	0.02	0.02	0.02	0.03
	of socket buffers
9	Send physical address	0.01	0.00	0.00	0.00	0.00	0.00	0.00	0.00
	information to host
10	Notify host service that	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.04
	all addresses were sent
11	Receive notification that	0.01	0.01	0.02	0.01	0.00	0.00	0.00	0.00
	snapshot is complete
12	Unfreeze processes	0.04	0.03	0.04	0.04	0.05	0.04	0.03	0.02
13	Send checkpoint	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
	notification to the guest
	service
14	Receive physical	0.35	0.30	0.34	0.32	0.29	0.32	0.30	0.40
	address from the guest
	service
15	Receive notification that	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.04
	addresses were sent
16	Create checkpoint with	16.96	16.20	16.48	17.25	15.76	16.08	16.61	17.02
	the process excluded
17	Notify the guest that the	0.10	0.10	0.05	0.10	0.09	0.08	0.11	0.10
	checkpointing is
	completed
18	Receive notification that	0.04	0.04	0.04	0.04	0.04	0.04	0.04	0.04
	the checkpointing is
	completed
19	Kill the excluded	0.00	0.00	0.00	0.00	0.00	0.00	0.00	0.00
	processes
20	Flush the page cache	0.11	0.11	0.10	0.07	0.14	0.12	0.07	0.08
21	Unfreeze processes	0.10	0.08	0.09	0.11	0.09	0.05	0.08	0.05
22	Checkpointing	16.70	16.82	17.15	17.92	16.40	16.72	17.26	17.97
23	Restoration	10.71	12.41	13.26	10.13	10.76	10.52	10.17	12.22

Tables 1 and 2 give the execution time when performing checkpointing using VirtualBox's default mechanism and using SPARC, respectively. Each data point reported is an average of execution time over 5 runs. Note that the time it takes for VirtualBox to perform checkpointing depends on the number of memory pages that are dirty; the more pages are dirty, the longer time the checkpointing is performed. In our experiments, prior to checkpointing, we run a program which allocates large amounts of memory and fills the memory with random data. The average sizes of .sav file after checkpointing is around 630 MB. The column heading “Operations” in these two tables gives the various operations performed. In particular, in Table 1(b), operations 1-12 and 13-18 are conducted by the guest and host services to perform checkpointing respectively, operations 19-21 are performed by the guest service to restore the VM. Rows 22 and 23 in Table 1(b) give the overall checkpointing time and the over overall restoration time, respectively. Note that, because some of the operations are performed in parallel by the guest and the host service, the numbers in row 22 are slightly higher than the actual execution time.

Observe from Tables 1(a) and 1(b) that, SPARC imposes 0:51%-7:01% overhead on checkpointing, 1:38%-2:51% overhead on restoration, and 1:02%-5:29% of overall overhead. The overheads of SPARC can be further reduced by using system-specific optimizations. For example, in VirtualBox the overhead of communication between host and guest services can likely be reduced by using the Host-Guest communication mechanism. This however, comes with cost of added implementation complexity.

Hardware Overview

FIG. 6 (see U.S. Pat. No. 7,702,660, expressly incorporated herein by reference), shows a block diagram that illustrates a computer system 400 upon which an embodiment may be implemented. Computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a processor 404 coupled with bus 402 for processing information. Computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Computer system 400 further includes a read only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk or optical disk, is provided and coupled to bus 402 for storing information and instructions. The computer system may also employ non-volatile memory, such as FRAM and/or MRAM.

The computer system may include a graphics processing unit (GPU), which, for example, provides a parallel processing system which is architected, for example, as a single instruction-multiple data (SIMD) processor. Such a GPU may be used to efficiently compute transforms and other readily parallelized and processed according to mainly consecutive unbranched instruction codes.

Computer system 400 may be coupled via bus 402 to a display 412, such as a liquid crystal display (LCD), for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

As discussed above, the present technology provides an alternate or supplemental user input system and method, which may advantageously be used in conjunction with other user interface functions which employ the same camera or cameras.

The technology is related to the use of computer system 400 for implementing the techniques described herein. According to one embodiment, those techniques are performed by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another machine-readable medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions for implementation. Thus, embodiments of are not limited to any specific combination of hardware circuitry and software.

The term “machine-readable medium” as used herein refers to any medium that participates in providing data that causes a machine to operation in a specific fashion. In an embodiment implemented using computer system 400, various machine-readable media are involved, for example, in providing instructions to processor 404 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, semiconductor devices, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. All such media must be tangible to enable the instructions carried by the media to be detected by a physical mechanism that reads the instructions into a machine. Wireless or wired communications, using digitally modulated electromagnetic waves are preferred.

Common forms of machine-readable media include, for example, hard disk (or other magnetic medium), CD-ROM, DVD-ROM (or other optical or magnetoptical medium), semiconductor memory such as RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read. Various forms of machine-readable media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution.

For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over the Internet through an automated computer communication network. An interface local to computer system 400, such as an Internet router, can receive the data and communicate using a wireless Ethernet protocol (e.g., IEEE-802.11n) to a compatible receiver, and place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404.

Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to a network link 420 that is connected to a local network 422. For example, communication interface 418 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 420 typically provides data communication through one or more networks to other data devices. For example, network link 420 may provide a connection through local network 422 to a host computer 424 or to data equipment operated by an Internet Service Provider (ISP) 426. ISP 426 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 420 and through communication interface 418, which carry the digital data to and from computer system 400, are exemplary forms of carrier waves transporting the information.

Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418.

The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution.

U.S. 2012/0173732, expressly incorporated herein by reference, discloses various embodiments of computer systems, the elements of which may be combined or subcombined according to the various permutations.

In this description, several preferred embodiments were discussed. It is understood that this broad invention is not limited to the embodiments discussed herein, but rather is composed of the various combinations, subcombinations and permutations thereof of the elements disclosed herein. The invention is limited only by the following claims.

References (Each of the following references is expressly incorporated herein by reference in its entirety.)

• [1] slock. tools.suckless.org/slock.
• [2] Vmware ace virtualization suite. www.vmware.com/products/ace/.
• [3] Xfree86. www.xfree86.org/4.2.0/xwininfo.1.html.
• [4] Xfree86. www.xfree86.org/current/xprop.1.html.
• [5] D. P. Bovet and M. C. Ph. Understanding the Linux Kernel, Third Edition. O'Reilly Media, 3 edition, November 2005.
• [6] J. Chow, B. Pfaff, T. Garfinkel, K. Christopher, and M. Rosenblum. Understanding data lifetime via whole system simulation. In Proceedings of USENIX Security Symposium, pages 22-22, 2004.
• [7] J. Chow, B. Pfaff, T. Garfinkel, and M. Rosenblum. Shredding your garbage: reducing data lifetime through secure deallocation. In Proceedings of the USENIX Security Symposium, pages 22-22, 2005.
• [8] J. Corbet, A. Rubini, and G. Kroah-Hartman. Linux Device Drivers, 3rd Edition. O'Reilly Media, Inc., 2005.
• [9] S. Davidoff. Cleartext passwords in linux memory. www.philosecurity.org, 2008.
• [10] A. Dinaburg, P. Royal, M. Sharif, and W. Lee. Ether: malware analysis via hardware virtualization extensions. In 15th ACM conference on Computer and communications security, pages 51-62, 2008.
• [11] G. W. Dunlap, S. T. King, S. Cinar, M. A. Basrai, and P. M. Chen. Revirt: Enabling intrusion analysis through virtual-machine logging and replay. In In Proceedings of the 2002 Symposium on Operating Systems Design and Implementation (OSDI), pages 211-224, 2002.
• [12] T. Garfinkel, B. Pfaff, J. Chow, and M. Rosenblum. Data lifetime is a systems problem. In Proc. of ACM SIGOPS European workshop. ACM, 2004.
• [13] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: a virtual machine-based platform for trusted computing. pages 193-206. ACM Press, 2003.
• [14] T. Garfinkel and M. Rosenblum. A virtual machine introspection based architecture for intrusion detection. In Proc. Network and Distributed Systems Security Symposium, pages, pages 191-206, 2003.
• [15] T. Garfinkel and M. Rosenblum. When virtual is harder than real: security challenges in virtual machine based computing environments. In Proceedings of the 10th conference on Hot Topics in Operating Systems, pages 20-20, 2005.
• [16] Google Corp. Inter-process communication. dev.chromium.org/developers/design-documents/inter-process-communication.
• [17] A. Joshi, S. T. King, G. W. Dunlap, and P. M. Chen. Detecting past and present intrusions through vulnerability-specific predicates. In Proceedings of the twentieth ACM symposium on Operating systems principles, pages 91-104, 2005.
• [18] S. T. King, G. W. Dunlap, and P. M. Chen. Debugging operating systems with time-traveling virtual machines. pages 1-15, 2005.
• [19] K. Kourai and S. Chiba. Hyperspector: Virtual distributed monitoring environments for secure intrusion detection. In ACM/USENIX International Conference on Virtual Execution Environments, pages 197-207, 2005.
• [20] D. Lezcano. Linux containers. lxc.sourceforge.net/lxc.html.
• [21] Microsoft Corp. Hyper-v server 2008 r2.www.microsoft.com/hyper-v-server/en/us/overview.aspx.
• [22] A. M. Nguyen, N. Schear, H. Jung, A. Godiyal, S. T. King, and H. D. Nguyen. Mavmm: Lightweight and purpose built vmm for malware analysis. In Annual Computer Security Applications Conference, pages 441-450, 2009.
• [23] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youseff, and D. Zagorodnov. The eucalyptus open-source cloud-computing system. In Proceedings of the 9th IEEE/ACM International Symposium on Cluster Computing and the Grid, pages 124-131, 2009.
• [24] D. A. S. d. Oliveira and S. F. Wu. Protecting kernel code and data with a virtualization-aware collaborative operating system. In Annual Computer Security Applications Conference, pages 451-460, 2009.
• [25] Oracle Corp. Virtualbox. www.VirtualBox.org.
• [26] B. D. Payne, M. Carbone, M. Sharif, and W. Lee. Lares: An architecture for secure active monitoring using virtualization. In IEEE Symposium on Security and Privacy, pages 233-247, 2008.
• [27] R. Riley, X. Jiang, and D. Xu. Guest-transparent prevention of kernel rootkits with vmm-based memory shadowing. In the 11th international symposium on Recent Advances in Intrusion Detection, pages 1-20, 2008.
• [28] N. Santos, K. P. Gummadi, and R. Rodrigues. Towards trusted cloud computing. In HOTCLOUD, 2009.
• [29] A. Seshadri, M. Luk, N. Qu, and A. Perrig. Secvisor: a tiny hypervisor to provide lifetime kernel code integrity for commodity uses. In Proceedings of Twenty-First ACM SIGOPS symposium on Operating Systems Principles, pages 335-350, 2007.
• [30] D. A. Solomon and M. Russinovich. Inside Microsoft Windows 2000. Microsoft Press, 2000.
• [31] VMware.Cloud computing.www.vmware.com/solutions/cloud-computing/.
• [32] VMware Inc. www.vmware.com/.
• [33] VMware Inc. Vmware infrastructure. www.vmware.com/landing_pages/discover.html.
• [34] Xen. Xen cloud platform—advanced virtualization infrastructure for the clouds. www.xen.org/products/cloudxen.html.
• [35] A. Kivity, Y. Kamay, D. Laor, U. Lublin, and A. Liguori. kvm: the linux virtual machine monitor. In Proc. of the Linux Symposium, pages 225-230, June 2007.
• [36] M. Balduzzi, J. Zaddach, D. Balzarotti, E. Kirda, and S. Loureiro. A security analysis of amazon's elastic compute cloud service. In ACM Symposium on Applied Computing, pages 1427-1434, 2012.
• [37] OpenVZ. Container-based Virtualization for Linux, www.openvz.com/.
• [38] M. I. Gofman, R. Luo, P. Yang, and K. Gopalan. SPARC: A security and privacy aware virtual machine checkpointing mechanism. In Proceedings of the 10th annual ACM Workshop on Privacy in the Electronic Society (WPES), in conjunction with the ACM Conference on Computer and Communications Security (CCS), pages 115-124, 2011.

Claims

1. A method of performing a checkpointing process within a virtual machine, comprising: (a) identifying a set of memory pages comprising user space memory pages and kernel space memory pages occupied by at least one application executing under control of a hypervisor of the virtual machine;(b) distinguishing a first subset of the set of memory pages comprising private user space memory pages and private kernel space memory pages occupied by the at least one application which represent private information from a second subset of the set of memory pages comprising the user space memory pages, and the kernel space memory pages occupied by the at least one application which do not represent the private information to the hypervisor; and(c) persistently storing a checkpoint file representing a state of the hypervisor comprising the identifications of the second subset of the set of memory pages, substantially without the first subset of the set of memory pages.

2. The method according to claim 1, further comprising restoring a prior state of the hypervisor from the persistently stored checkpoint file, from the first second subset of memory pages and without the first subset of memory pages, and resuming the at least one application which are not dependent on the first subset of the set of memory pages.

3. The method according to claim 1, further comprising freezing all processes of the at least one application in a user space, except the checkpointing process, while the checkpoint file is created.

4. The method according to claim 1, further comprising determining inter-process dependencies comprising information in TTY buffers, socket buffers, pipe buffers, and FIFO buffers, wherein the checkpoint file further comprises information for resuming the at least one application which, based on the inter-process dependencies, comprise processes which are not dependent on the first subset of the set of memory pages.

5. The method according to claim 1, further comprising segregating a first process container which encapsulates at least all memory pages associated with a respective application, separate from a second process container which encapsulates memory pages associated with another respective application, wherein the first process container and the second process container are separately stored within the checkpoint file.

6. The method according to claim 1, further comprising identifying the inter-process dependencies for the at least one application by at least a static analysis.

7. The method according to claim 1, further comprising identifying inter-process dependencies for a plurality of different applications by at least a dynamic analysis.

8. The method according to claim 1, further comprising determining an open communication of the at least one application, and deferring creation of the checkpoint file with respect to the at least one application until completion of the open communication.

9. The method according to claim 1, further comprising: communicating a message to the at least one application prior to creating the checkpoint file;assuming a safe state by the at least one application in response to the message, in which private information is removed from at least a portion of the user space memory pages and the kernel space memory pages so that the at least a portion of the user space memory pages and the kernel space memory pages are within the second subset of the set of memory pages;andafter storing the checkpoint file, reverting the at least one application to a normal operation state.

10. The method according to claim 9, further comprising: restoring the state of the hypervisor from the checkpoint file; andinforming the at least one application that the hypervisor is restored from the checkpoint file.

11. The method according to claim 1, further comprising, under control of the checkpointing process: sanitizing kernel space memory by pausing system calls and I/O requests from the at least one application by the kernel;completing or flushing any pending I/O operations of the at least one application;removing data from all I/O buffers after the completion of the I/O operations; andpreparing the checkpoint file for storage after said sanitizing, completing or flushing, and removing.

12. A method for checkpointing a virtual machine, comprising performing, by a checkpointing process executing on the virtual machine under control of a hypervisor: (a) pausing system calls and I/O requests from at least one application, complete or flush pending I/O operations, and zeroing out all I/O buffers after the completion of the I/O operations;(b) identifying user space memory pages and kernel space memory locations of the at least one application, which contain private information and user space memory pages and kernel space memory locations of the at least one application that exclude private information;(c) creating a checkpoint file comprising at least the user space memory pages and kernel space memory locations of the at least one application that exclude the private information, and which does not comprise the user space memory pages and kernel space memory locations which contain private information; and(d) recommencing system calls and I/O requests from the at least one application.

13. The method according to claim 12, further comprising determining inter-process dependencies, wherein the checkpoint file further comprises information for selectively, based on the inter-process dependencies, resuming respective applications upon restoration of the virtual machine from the checkpoint file, which are not dependent on the user space memory pages and kernel space memory locations which contain private information.

14. The method according to claim 13, further comprising determining inter-process dependencies for the at least one application by static analysis and dynamic analysis.

15. The method according to claim 12, further comprising restoring the virtual machine to substantially resume operation, based on the created checkpoint file.

16. The method according to claim 12, further comprising: monitoring an input-output data stream communication from non-program memory sources to the virtual machine;storing a series of states representing activities of the at least one application with respect to the monitored input-output data stream communications;tagging instances of data within the created checkpoint file corresponding to the monitored input-output data stream communication; andrestoring the virtual machine to substantially resume operation, based on the created checkpoint file, wherein a state of the at least one process is rolled back to a state prior to a respective monitored input-output data stream communication.

17. The method according to claim 16, wherein memory pages within the created checkpoint file which contain the tagged instances of data are excluded or obscured.

18. The method according to claim 12, further comprising determining an ongoing communication a respective application, and deferring creation of the checkpoint file with respect to the respective application until completion of the communication.

19. The method according to claim 12, further comprising: communicating a message to the at least one application prior to creating the checkpoint file;assuming a safe state by the at least one application, in which confidential information is removed from the memory pages which are captured within the checkpoint file;sanitizing kernel space memory by pausing system calls and I/O requests from the at least one application by the kernel;completing or flushing any pending I/O operations of the at least one application;removing data from all I/O buffers after the completion of the I/O operations; andafter creating the checkpoint file, reverting the at least one application to a normal operation state.

20. A system for performing a checkpointing process within a virtual machine, comprising: a memory configured to store memory pages of a virtual machine controlled having a hypervisor controlling execution of at least one application;the hypervisor controlling execution of a set of checkpointing processes, comprising:(a) a process to identify a set of memory pages comprising user space memory pages and kernel space memory pages occupied by at least one application executing under control of a hypervisor of the virtual machine;(b) a process to distinguish a first subset of the set of memory pages comprising private user space memory pages and private kernel space memory pages occupied by the at least one application which represent private information from a second subset of the set of memory pages comprising the user space memory pages, and the kernel space memory pages occupied by the at least one application which do not represent the private information to the hypervisor;(c) a process to persistently store a checkpoint file representing a state of the hypervisor comprising the identifications of the second subset of the set of memory pages, substantially without the first subset of the set of memory pages.