Source: https://patents.google.com/patent/US9672052B1/en
Timestamp: 2019-04-23 18:53:08
Document Index: 140295988

Matched Legal Cases: ['art 2', 'art 2', 'art-2', 'art 6', 'art-6', 'art 6', 'art-6']

US9672052B1 - Secure inter-process communication - Google Patents
Secure inter-process communication Download PDF
US9672052B1
US9672052B1 US13/398,715 US201213398715A US9672052B1 US 9672052 B1 US9672052 B1 US 9672052B1 US 201213398715 A US201213398715 A US 201213398715A US 9672052 B1 US9672052 B1 US 9672052B1
US13/398,715
Eric A. Moon
2012-02-16 Application filed by Google LLC filed Critical Google LLC
2012-02-16 Priority to US13/398,715 priority Critical patent/US9672052B1/en
2012-05-11 Assigned to GOOGLE INC. reassignment GOOGLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MOON, ERIC A., BERRETH, FRANK, HENRY, ROBERT R.
2017-06-06 Publication of US9672052B1 publication Critical patent/US9672052B1/en
Among other disclosed subject matter, a system includes a secure execution domain configured to execute trusted processes. The system also includes a hardware virtualization component in the secure execution domain and configured to implement a virtual machine. The virtual machine is a hardware virtualization of a data processing apparatus and includes a shared virtual memory device and a guest software application coupled to the shared virtual memory device. The system also includes a trusted process in the secure execution domain, separate from the virtual machine and coupled to the shared virtual memory device. The trusted process is configured to communicate with the guest software application through the shared virtual memory device. Communication with the guest software application includes secure communication.
This document relates to inter-process communication, and more specifically to inter-process communications between a trusted process and an untrusted process using a virtual memory device.
Cloud computing is network-based computing in which typically large collections of servers housed in data centers or “server farms” provide computational resources and data storage as needed to remote end users. Some cloud computing services provide access to software applications such as word processors and other commonly used applications to end users who interface with the applications through web browsers or other client-side software. Users' electronic data files are usually stored in the server farm rather than on the users' computing devices. Some cloud computing services allow end users to execute software applications in virtual machines.
This document describes systems that provide secure communications between a virtual machine and a process external to the virtual machine.
In one aspect, a system includes a secure execution domain configured to execute trusted processes. The system also includes a hardware virtualization component in the secure execution domain and configured to implement a virtual machine. The virtual machine is a hardware virtualization of a data processing apparatus and includes a shared virtual memory device and a guest software application coupled to the shared virtual memory device. The system also includes a trusted process in the secure execution domain, separate from the virtual machine and coupled to the shared virtual memory device. The trusted process is configured to communicate with the guest software application through the shared virtual memory device. Communication with the guest software application includes secure communication.
These and other aspects can optionally include one or more of the following features. The guest software application is isolated from resources associated with the secure execution domain and data stored in a database associated with the trusted process. The trusted process is configured to provide data from the database to the guest software application using the shared virtual memory device. The hardware virtualization component is further configured to implement a communication channel coupled to the virtual machine and to the trusted process, wherein the communication channel includes a signal. The hardware virtualization component is further configured to implement a memory driver associated with the shared virtual memory device. The shared virtual memory device comprises a semaphore configured to control access to the shared virtual memory device. The shared virtual memory device comprises a virtualization of a PCI device including memory.
In another aspect, a method includes executing an operating system on a data processing apparatus that implements a secure execution domain that is configured to execute trusted processes. The trusted processes include a hardware virtualization component to implement a virtual machine. The method includes executing the virtual machine in the secure execution domain. The virtual machine is a hardware virtualization of a data processing apparatus and includes a shared virtual memory device and a guest software application coupled to the shared virtual memory device. The method includes exchanging data between the guest software application and a particular trusted process using the shared virtual memory device, wherein the particular trusted process is separate from the virtual machine.
These and other aspects can optionally include one or more of the following features. The method can also include writing data to the shared virtual memory device, wherein the data is from the particular trusted process; providing a signal to the guest software application to indicate that data has been written into the shared virtual memory device; and in response to the signal, reading the data from the shared virtual memory device, wherein the data is read from the shared virtual memory device by the guest software application. The signal includes a flag or interrupt signal. The guest software application is isolated from resources associated with the secure execution domain and data stored in a database associated with the trusted processes. The method also includes checking out a semaphore before writing data, wherein the semaphore is configured to control access to the shared virtual memory device.
Particular aspects of the subject matter described can be implemented to realize one or more of the following advantages. For example, software applications, such as user applications hosted on a virtual machine that has been isolated from particular resources and/or data, can exchange data and/or otherwise interact with processes external to the virtual machine using shared virtual memory. In addition, security created by isolating the virtual machine can be preserved because software application cannot access memory or resources external to the virtual machine.
FIG. 1 is a block diagram of an example system that provides secure communication between a virtual machine and a trusted process.
FIG. 2A is a flowchart of an example process for exchanging communications between a virtual machine and a trusted process.
FIG. 2B is a flowchart of an example process for exchanging communications between a virtual machine and a trusted process.
FIG. 3 is a block diagram of an example host machine.
Systems and methods are described for secure communications between a virtual machine and a trusted process. A computing device, such as a server or a computer, can execute a first and second trusted process. The first trusted process can be executed in a secure execution domain, such as an operating system running on the computing device, and can include a hardware virtualization component that can be used to implement virtual machines that include virtual devices (e.g., virtual memory, virtual networking interfaces and modules, etc.). A virtual machine can execute an operating system that can host a guest application. Although the guest application can be sandboxed by the virtual machine, the guest application can exchange data and/or communicate with the second trusted process using a virtual memory device. The communications between the second trusted process and the guest application can be secure because the guest application does not have access to memory and/or resources external to the virtual machine.
FIG. 1 is a block diagram of an example system 100 that provides secure communication between a virtual machine and a trusted process. The system 100 includes a physical machine 102 that is configured to implement trusted processes 104 a and 104 b. The physical machine 102 can be any type of data processing apparatus, such as a personal computer, a workstation, a server, etc. The physical machine 102 can be part of a collection of servers housed in a data center and can be configured to communicate with other servers and/or computing devices in the data center. The physical machine 102 can also be part of an internal network (e.g., an intranet). For example, the physical machine 102 can be connected to a company's internal network and communicate with other machines connected to the company's internal network. The physical machine 102 can also communicate with machines that are not part of a company's internal network using the Internet. For example, the physical machine 102 can communicate with a user's computing device using the Internet. In some implementations, the physical machine 102 can be part of a cloud computing system and host one or more virtual machines 108 that host guest applications 112.
The trusted processes 104 a and 104 b can be software processes or applications that are initiated by an operator or administrator of the physical machine 102 and are executed by the physical machine 102 in a secure execution domain. The phrase “secure execution domain” as used herein encompasses its plain and ordinary meaning, including, but not limited to an operating system running on the physical machine 102 controlled or operated by an administrator or entity associated with the physical machine 102 (e.g., the owner or provider of the physical machine 102. As discussed below, the trusted processes 104 a and 104 b may execute on two or more processors or systems (not pictured). The trusted process 104 b can be an application that can access resources and data that are not accessible by other processes. For example, the trusted process 104 b can be a process (e.g., a Map Reduce Process or video processing/compressing algorithm) that can access databases or other resources and provide the data stored in the databases to other applications or processes (e.g., a guest application 112). The map-reduce technique applies at least one application-specific map operation to the input data to produce intermediate data values, wherein the map operation is parallelized across multiple processors in the parallel processing or distributed environment. A plurality of intermediate data structures may be used to store the intermediate data values. One or more application-independent reduce modules are configured to retrieve the intermediate data values and to apply at least one application-specific reduce operation to the intermediate data values to provide output data. In some implementations, the trusted process 104 a can implement a reduce module and a user software application (e.g., the guest application 112) can implement a map module. An example Map Reduce Process is described in U.S. Pat. No. 7,650,331, which is incorporated by reference for all purposes.
In some implementations, the trusted process 104 b is running on a physical machine that is different from the physical machine 102 that is executing the trusted process 104 a but is connected to the physical machine 102 via an internal network or Internet. In general, a process is a trusted process if it is initiated by an operator or administrator associated with the physical machine 102 and executed on the physical machine 102 as opposed to being executed on a virtual machine 108.
The trusted process 104 a can include a hardware virtualization component 106. The hardware virtualization component 106 can be used to implement virtual devices. For example, in some implementations, the hardware virtualization component 106 can include a virtualization component, e.g., a Kernel-based Virtualization Machine, and a processor emulator, e.g., QEMU, to virtualize and emulate hardware devices, such as a virtual machine 108, a shared memory driver 110 and a communication channel 111. Although FIG. 1 illustrates a single virtual machine 108, a shared memory driver 110 and a single communication channel 111, in some implementations, multiple virtual machines, various types of drivers and multiple communication channels can be implemented on the same physical machine. In addition, other virtual hardware devices (e.g., a network access interface) can be virtualized.
The virtual machine 108 can be a hardware virtualization of a data processing apparatus (e.g., a computer or server). For example, the virtual machine 108 can be a virtualized computer that includes an operating system (e.g., a guest operating system), a guest application 112 and a shared virtual memory device 114. The virtual machine 108 can be associated with an end user. For example, virtual machine 108 can be assigned to or be associated with an end user of the system 100 (e.g., a user that rents or purchases computing resources from the operator of a cloud computing system). The end user can host various data and/or software applications on the virtual machine 108. In addition, the end user can execute applications (e.g., guest application 112) on the virtual machine 108.
The virtual machine 108 can be isolated or partially isolated from the physical machine 102 and/or the trusted processes 104 a and 104 b. The term “isolated” as used herein encompasses its plain and ordinary meaning, including but not limited to the virtual machine 108 having limited access to the hardware and/or software resources not included in the virtual machine 108 or the hardware virtualization component 108. For example, the virtual machine 108 can be sandboxed (e.g., executed in a controlled environment with a limited set of resources) and have limited access to hardware resources associated with the physical machine (e.g., network interface components, cache, memory, etc.) and can have limited access to software resources associated with the physical machine and/or trusted processes 104 a and 104 b (e.g., databases, operating systems, etc.).
The guest application 112 can be a software application executed on the virtual machine 108 by the end user. In some implementations, the guest application 112 can expect input or data from a trusted source (e.g., the trusted process 104 b). For example, the trusted process 104 b can retrieve data from a database, a network or a data center service (e.g., proprietary business data, advertising data, etc.) and provide that data to the guest application 112. In addition, the guest application 112 can provide data to the trusted process 104 b. In some implementations, the guest application 112 can provide data to end users associated with the virtual machine 108. For example, the guest application 112 can process or calculate data received from the trusted process 104 b and provide the processed data to the end user.
The guest application 112 is sometimes referred to as an untrusted process because the guest application 112 might be malicious software meant to interfere with the physical machine 102, the trusted processes 104 a and 104 b, and/or data associated with the physical machine 102 or the trusted processes 104 a and 104 b (e.g., proprietary business data, user records or accounts, etc.). Because the virtual machine 108 is isolated from the physical machine 102 and the trusted processes 104 a and 104 b, the guest application 112 is also isolated from the physical machine 102 and the trusted processes 104 a and 104 b (e.g., sandboxed by the virtual machine 108). This isolation or sandboxing can limit the guest application's ability to interfere with the physical machine 102 or trusted processes 104 a and 104 b can contain any malicious software within the virtual machine 108. However, the guest application 112 can access the virtual machine's virtualized resources and virtualized components. For example, the guest application 112 can interact with the guest OS and/or virtual hardware devices (e.g., the shared virtual memory device 114).
The shared virtual memory 114 can be a virtual or emulated memory device. For example, the shared virtual memory 114 can be a virtual Peripheral Component Interconnect (PCI)-device that includes memory, e.g., a virtual PCI video card that includes a frame buffer. In some implementations, the shared virtual memory 114 can be other types of shared virtual memory. For example, in some implementations, the shared virtual memory 114 can be a dual ported memory device (e.g., a dual ported RAM). The shared virtual memory 114 can be implemented as a virtual device by the shared memory driver 110. The shared memory driver 110 is not included in the virtual machine 108 and is included in the hardware virtualization component 106.
The shared virtual memory 114 can be memory mapped or accessible to software (e.g., coupled) such that the shared virtual memory 114 can be accessed by the guest OS, the guest application 112, the shared memory driver 110, the communication channel 111, the trusted process 104 b and/or other applications running on the virtual machine 108. For example, the shared virtual memory 114 can be associated with Application Programming Interfaces (“APIs”) that can be used by the trusted process 104 b and/or the guest application 112 to access the shared virtual memory 114. In some implementations, the shared virtual memory 114 is associated with a first API to be used by the trusted process 104 b to access the shared virtual memory 114 (e.g., read data from the shared virtual memory 114 and/or write data to the shared virtual memory 114) and a second API that is used by the guest application 112 to access the shared virtual memory 114.
The shared virtual memory 114 can include a device driver that allows the guest application 112 and other applications and/or devices included in the virtual machine 108 to communicate with the shared virtual memory 114.
In some implementations, the shared virtual memory 114 can include a semaphore that can be used to control access to the shared virtual memory 114. The guest application 112 and the trusted process 104 b can interact with the semaphore using an API associated with the shared virtual memory 114. For example, the guest application 112 can use an API to check out the semaphore before the guest application 112 writes data to the shared virtual memory 114. While the semaphore is checked out to the guest application 112, other applications and/or processes should not access the shared virtual memory 114 until the guest application 112 releases the semaphore. After the guest application 112 has written data to the shared virtual memory 114, the guest application 112 can release the semaphore using an API. In some implementations, the shared virtual memory 114 manages the semaphore automatically in response to the APIs. For example, after receiving a read instruction or a write instruction, the shared virtual memory 114 can check out and release the semaphore as appropriate. In some implementations, the shared virtual memory 114 can include multiple semaphores, each associated with different portions of shared virtual memory 114. In such implementations, the requesting process can request (or receive) a semaphore for only the portion of the memory to which it would like to write. This can allow processes to write simultaneously to multiple portions of the shared virtual memory 114 if there is no conflict in the writes.
After the guest application 112 writes data into the shared virtual memory 114, a flag (e.g., a doorbell register) included in the communication channel 111 can be set to indicate that data has been written into the shared virtual memory 114. For example, after data is written into the shared virtual memory 114, the guest application 112 can use an API associated with the communication channel 111 to set the flag or trigger an interrupt to alert the trusted process 104 b that data has been written to the shared virtual memory 114. In some implementations, the trusted process 104 b periodically or continuously polls the doorbell register to determine if data has been written to the shared virtual memory 114. The communication channel 111 can be a communication channel to facilitate inter-process communications (e.g., communications between the trusted processes 104 a and 104 b). For example, the communication channel 111 can be a Unix domain socket or a named pipe between the virtual machine and the trusted process 104 b. In some implementations, the communication channel 111 can be associated with APIs that allow the trusted process 104 b and/or the guest application 112 to exchange data without the use of a shared virtual memory 114. For example, the communication channel 111 can be a network connection that allows the guest application 112 to exchange data with the trusted process 104 b.
FIG. 2A is a flowchart of an example process 200 to exchange communications between a virtual machine and a trusted process. The process 200 begins when the semaphore is checked out (at 202). For example, the guest application 112 running on the virtual machine 108 can check out the semaphore using an API associated with the shared virtual memory 114.
Data is then written into the shared virtual memory (at 204). For example, the guest application 112 can write data into the shared virtual memory 114 using an API associated with the shared virtual memory 114. In some implementations, the shared virtual memory 114 is memory mapped such that the guest application 112 can write data into the shared virtual memory 114. After the data is written into the shared virtual memory, the semaphore can be released (at 206). For example, the guest application 112 can release the semaphore using an API associated with the shared virtual memory 114.
After the semaphore is released, a flag can be set (at 208). For example, the guest application 112 can set a flag (e.g., a doorbell register) to alert the trusted process 104 b of the data in the shared virtual memory 114. In some implementations, the guest application 112 can use an API associated with the communication channel 111 to set a flag (e.g., a doorbell register) to alert the trusted process 104 b that data has been written into the shared virtual memory 114.
In response to the flag, the trusted process can check out the semaphore (at 210). For example, the trusted process 104 b can use an API associated with the shared virtual memory 114 to check out the semaphore. The trusted process can then read data from the shared virtual memory (at 212). For example, the trusted process 104 b can use an API associated with the shared virtual memory 114 to read data from the shared virtual memory 114.
After the data has been provided to the trusted process, the semaphore can be released (at 216). For example, the trusted process 104 b can use an API associated with the shared virtual memory 114 to release the semaphore.
FIG. 2B is a flowchart of an example process 250 to exchange communications between a virtual machine and a trusted process. The process 250 begins when the trusted process checks out the semaphore (at 252). For example, the trusted process 104 b can use an API associated with the virtual memory 114 to check out the semaphore. After the semaphore is checked out, the trusted process can send a write data to the shared virtual memory address (at 254). For example, the trusted process 104 b can use an API associated with the shared virtual memory 114 to write data into the shared virtual memory 114. The trusted process 104 b can send the data or a pointer to the data to the shared virtual memory 114 as part of the write instruction.
The trusted process can then release the semaphore (at 258). For example, the trusted process 104 b can use an API associated with the shared virtual memory 114 to release the semaphore. The shared virtual memory can then set a flag to alert the guest application that data has been written into the shared virtual memory 114 (at 260). For example, the trusted process 104 b can use an API associated with the communication channel 111 to insert an interrupt for the shared virtual memory 114 to alert the guest application 112 that data has been written into the virtual memory 114.
After the guest application detects the flag, the guest application can check out the semaphore (at 262). For example, after the guest application 112 detects that the doorbell register indicates that data has been written into the shared virtual memory 114 the guest application 112 can use an API associated with the shared virtual memory 114 to check out the semaphore. The guest application then reads data from the shared virtual memory (at 264). For example, the guest application 112 can use an API associated with the shared virtual memory 114 to read data from a particular memory address associated with data received from the trusted process 104 b. After the data has been read, the guest application 112 can release the semaphore. For example, the guest application can use an API associated with the shared virtual memory 114 to release the semaphore.
FIG. 3 is a schematic diagram of an example physical machine. The physical machine 300 generally consists of a data processing apparatus 302. The data processing apparatus 302 can optionally communicate with one or more other computers 390 through a network 380. While only one data processing apparatus 302 is shown in FIG. 3, multiple data processing apparatus can be used in one or more locations. The data processing apparatus 302 includes various modules, e.g. executable software programs. One of the modules is the kernel 306 of a host operating system (e.g., trusted process 104 a). A communication process module 304 is configured to establish VPNs, encapsulate packets and to de-encapsulate packets. A hardware virtualization component (e.g., hardware virtualization component 106) includes virtual hardware (e.g., virtual machine 106) that includes a guest operating system (e.g., guest OS), and guest applications (e.g., guest application 112). Although several software modules are illustrated, there may be fewer or more software modules. Moreover, the software modules can be distributed on one or more data processing apparatus connected by one or more networks or other suitable communication mediums.
The data processing apparatus 302 also includes hardware or firmware devices including one or more processors 312, one or more additional devices 314, a computer readable medium 316, a communication interface 318, and optionally one or more user interface devices 320. Each processor 312 is capable of processing instructions for execution within the data processing apparatus 302. In some implementations, the processor 312 is a single or multi-threaded processor. Each processor 312 is capable of processing instructions stored on the computer readable medium 316 or on a storage device such as one of the additional devices 314. The data processing apparatus 302 uses its communication interface 318 to communicate with one or more computers 390, for example, over a network 380. Examples of user interface devices 320 include a display, a camera, a speaker, a microphone, a tactile feedback device, a keyboard, and a mouse. The data processing apparatus 302 can store instructions that implement operations associated with the modules described above, for example, on the computer readable medium 316 or one or more additional devices 314, for example, one or more of a floppy disk device, a hard disk device, an optical disk device, or a tape device.
1. A system having one or more physical machines, comprising:
a secure execution domain established on a host operating system executing a first trusted process;
a hardware virtualization component operating within the secure execution domain and configured to implement a virtual machine, wherein the virtual machine is a hardware virtualization of a data processing apparatus, and wherein the virtual machine is isolated such that the virtual machine has limited access to resources not included in the virtual machine and the hardware virtualization component, and comprises:
a shared virtual memory device within the virtual machine; and
a guest software application, executed within the virtual machine and communicatively coupled to the shared virtual memory device, the virtual machine being configured such that the guest software application executed in the virtual machine does not have access to memory and resources that are external to the virtual machine and the guest software application can communicate with a second trusted process executed within the secure execution domain but external to the virtual machine using only the shared virtual memory device;
the second trusted process running in the secure execution domain on the host operating system, the second trusted process being separate from the virtual machine and enabled to access at least some of the resources of the secure execution domain, wherein the second trusted process is communicatively coupled to the shared virtual memory device and configured to communicate with the guest software application only through the shared virtual memory device via a communication channel using a memory driver associated with the snared virtual memory device,
wherein communications between the second trusted process and the guest software application are secure communications based on the guest software application being configured such that the guest software application does not have access to memory and resources that are external to the virtual machine and can communicate with the second trusted process using only the shared virtual memory device.
2. The system of claim 1 wherein the second trusted process is configured to provide data from a database to the guest software application using the shared virtual memory device.
3. The system of claim 1 wherein the secure communication between the second trusted process and guest software application comprises a Unix domain socket.
4. The system of claim 1 wherein the shared virtual memory device comprises a semaphore configured to control access to the shared virtual memory device.
5. The system of claim 1 wherein the guest software application comprises an untrusted software application.
6. The system of claim 5 wherein the untrusted software application comprises a software application associated with a third party user that is associated with the virtual machine.
7. The system of claim 1 wherein the second trusted process comprises a software application associated with an operator of the secure execution domain.
8. The system of claim 1 wherein the shared virtual memory device comprises a virtualization of a Peripheral Component Interconnect device including memory.
9. The system of claim 1 wherein a communication between the second trusted process and the guest software application comprises:
data written into the shared virtual memory device; and
the signal provided to the guest software application to indicate that data has been written into the shared virtual memory device, wherein the signal is provided to the guest software application using the communication channel.
executing, by one or more physical machines, a secure execution domain established on a host operating system executing a first trusted process;
executing a hardware virtualization component operating within the secure execution domain and the hardware virtualization component implementing a virtual machine, wherein the virtual machine is a hardware virtualization of a data processing apparatus, and wherein the virtual machine is isolated such that the virtual machine has limited access to resources not included in the virtual machine and the hardware virtualization component, and comprises:
executing the second trusted process, the second trusted process running in the secure execution domain on the host operating system, the second trusted process being separate from the virtual machine and enabled to access at least some of the resources of the secure execution domain, wherein the second trusted process is communicatively coupled to the shared virtual memory device and configured to communicate with the guest software application only through the shared virtual memory device via a communication channel using a memory driver associated with the shared virtual memory device; and
exchanging data between the guest software application and the second trusted process, wherein communications between the second trusted process and the guest software application are secure communications based on the guest software application being configured such that the guest software application does not have access to memory and resources that are external to the virtual machine and can communicate with the second trusted process using only the shared virtual memory device.
11. The computer-implemented method of claim 10, wherein exchanging data comprises:
writing data to the shared virtual memory device, wherein the data is from the second trusted process;
providing a signal to the guest software application to indicate that data has been written into the shared virtual memory device; and
in response to the signal, reading the data from the shared virtual memory device, wherein the data is read from the shared virtual memory device by the guest software application.
12. The computer-implemented method of claim 11, wherein the signal comprises a flag or an interrupt signal.
checking out a semaphore before writing data, wherein the semaphore is configured to control access to the shared virtual memory device.
14. The computer-implemented method of claim 10, wherein the shared virtual memory device comprises a virtualization of a Peripheral Component Interconnect device including memory or a dual ported memory device.
15. A non-transitory computer readable medium encoded with a computer program comprising instructions that, when executed, operate to cause a computer to perform operations of:
execute, on the computer, a secure execution domain established on a host operating system executing a first trusted process;
execute a hardware virtualization component operating within the secure execution domain and the hardware virtualization component implementing a virtual machine, wherein the virtual machine is a hardware virtualization of a data processing apparatus, and wherein the virtual machine is isolated such that the virtual machine has limited access to resources not included in the virtual machine and the hardware virtualization component, and comprises:
execute the second trusted process, the second trusted process running in the secure execution domain on the host operating system, the second trusted process being separate from the virtual machine and enabled to access at least some of the resources of the secure execution domain, wherein the second trusted process is communicatively coupled to the shared virtual memory device and configured to communicate with the guest software application only through the shared virtual memory device via a communication channel using a memory driver associated with the shared virtual memory device; and
exchange data between the guest software application and the second trusted process, wherein communications between the second trusted process and the guest software application are secure communications based on the guest software application being configured such that the guest software application does not have access to memory and resources that are external to the virtual machine and can communicate with the second trusted process using only the shared virtual memory device.
16. The computer readable medium of claim 15, further comprising instructions that, when executed, operate to cause the computer to perform operations:
17. The computer readable medium of claim 16, wherein the signal comprises a flag or an interrupt signal.
18. The computer readable medium of claim 16 further comprising instructions that, when executed, operate to cause the computer to perform operations:
US13/398,715 2012-02-16 2012-02-16 Secure inter-process communication Active 2035-03-31 US9672052B1 (en)
US13/398,715 US9672052B1 (en) 2012-02-16 2012-02-16 Secure inter-process communication
US9672052B1 true US9672052B1 (en) 2017-06-06
ID=58776395
US13/398,715 Active 2035-03-31 US9672052B1 (en) 2012-02-16 2012-02-16 Secure inter-process communication
US (1) US9672052B1 (en)
2012-02-16 US US13/398,715 patent/US9672052B1/en active Active
"Generic Routing Encapsulation". Creativecommons.org [online]. Creative Commons Attribution-Share Alike 3.0 Unported. [retrieved on Jan. 14, 2011]. Retrieved from the Internet: creativecommons.org/licenses/by-sa/3.0/ >, pp. 1-5.
"IPsec". Creativecommons.org [online]. Creative Commons Attribution-Share Alike 3.0 Unported. [retrieved on Jan. 14, 2011]. Retrieved from the Internet: creativecommons.org/licenses/by-sa/3.0 >, pp. 1-8.
‘Nagios’ [online]. "Monitoring Linux/Unix Machines," 2011, [retrieved on Feb. 3, 2011]. Retrieved from the Internet: nagios.sourceforge.net/docs/3—0/monitoring-linux.html > 1 page.
‘Nagios’ [online]. "Nagios Plugins," 2011, [retrieved on Feb. 3, 2011]. Retrieved from the Internet: agios.sourceforge.net/docs/3—0/plugins.html > 2 pages.
‘Zabbix’ [online]. "Zabbix 1.8: The Ultimate Open Source Monitoring Solution," 2001-2012, [retrieved on Feb. 3, 2011]. Retrieved from the Internet: .zabbix.com/features.php.> 1 page.
Abdull, AlastairIrvine, et al. "Generic Routing Encapsulation", [online] [retrieved on Jan. 4, 2011]. Retrieved from the Internet: creativecommons. org/ licenses/ by-sa/ 3. 0/>, 5 pages.
Amazon Elastic Compute Cloud, User Guide, API Version Mar. 1, 2012, pp. 97-103, downloaded from ocs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html?r=4276 on Mar. 18, 2012.
Anonymous, "Storage I/O Control Technical Overview and Consideration for Deployment," VMware vSphere™ 4.1, Jan. 1, 2010, XP05504491, retrieved from the internet: URL: http://www.vmware.com/fled/pdf/techpaper/WMW-vSphere41-SIOC.pdf; [retrieved on Nov. 21, 2012], 12 pages.
Apache HTTP Server Version 2.0. "Log Files." [Retrieved on Feb. 15, 2011]. Retrieved from the Internet httpd.apache.org/docs/2.0/logs.html>, 7 pages.
Benincosa. "Ganglia and Nagios, Part 2: Monitor enterprise clusters with Nagios—Install Nagios to effectively monitor a data center; make Ganglia and Nagios work together," 2009, 20 pages.
Bucket Explorer. "What is my AWS Access and Secret Key." [Retrieved Apr. 26, 2011]. Retrieved from the Internet .bucketexplorer.com/documentation/amazon-s3--what-is-my-aws-access-and-secret-key.html>, 1 page.
Cloud Computing Course, Part 2: Amazon's EC2, Marcel Gagne, Jun. 13, 2011. Retrieved from the Internet: /marcelgagne.com/content/cloud-computing-course-part-2-amazons-ec2>, 6 pages.
Gowalla. "API Documentation-Oauth." [Retrieved on Apr. 26, 2011]. Retrieved from the Internet /gowalla.com/api/docs/oauth>, 4 pages.
Gowalla. "API Documentation—Oauth." [Retrieved on Apr. 26, 2011]. Retrieved from the Internet /gowalla.com/api/docs/oauth>, 4 pages.
Hongkiat. "Amazon S3-The Beginner's Guide." [Retrieved on Apr. 26, 2011]. Retrieved from the Internet .hongkiat.com/blog/amazon-s3-the-beginners-guide/>, 9 pages.
Hongkiat. "Amazon S3—The Beginner's Guide." [Retrieved on Apr. 26, 2011]. Retrieved from the Internet .hongkiat.com/blog/amazon-s3-the-beginners-guide/>, 9 pages.
How to: Getting Started With Amazon EC2, Paul Stamatiou, Apr. 5, 2008. Retrieved from the Internet: <paulstamatiou.com/how-to-getting-started-with-amazon-ec2>, 25 pages.
Key Management in Cloud Datacenters, Security Stackexchange.com, Retrieved from the Internet on Nov. 18, 2011; Retrieved from: <security.stackexchange.com/questions/2514/key-management-in-cloud-datacenters>, 2 pages.
Laitinen, Aapo et al., Network Address Translation [Retrieved on Oct. 10, 2011] Retrieved from the Internet: en.wikipedia.org/wiki/Networkpages-Address-and-Port-Translation>, 11 pages.
Laitinen, Aapo et al., Network Address Translation [Retrieved on Oct. 10, 2011] Retrieved from the Internet: en.wikipedia.org/wiki/Networkpages—Address—and—Port—Translation>, 11 pages.
Managing Amazon EC2-SSH Login and Protecting Your Instances, Everyday's Findings, Monday, May 18, 2009, Retrieved from the Internet on Nov. 18, 2011; Retrieved from: blog.taggesell.de/index.php?/aarchives/73-Managing-Amazon-EC2., 6 pages.
Microsoft Support. "How to view and manage event logs in Event Viewer in Windows XP." May 7, 2007, version 3.5 [Retrieved on Feb. 15, 2011]. Retrieved from the Internet <support.microsoft.com/kb/308427>, 6 pages.
Mohebbi et al. ("ZIVM: a Zero-Copy inter-VM communication mechanism for cloud computing", computer and information science vol. 4, Nov. 2011, pp. 18-27). *
Moller, Jan, et al., "Internal Network Security", Feb. 1, 2000-May 18, 2001, Retrieved from the Internet: daimi.au.dk/˜fwiffo/thesis/>, 183 pages.
MSDN. "Visual Basic Concepts, Visual Studio 6.0: Centralized Error Handling." [Retrieved on Feb. 15, 2011]. Retrieved from the Internet <msdn.microsoft.com/en-us/library/aa240795(d=printer, v=vs.60).aspx>, 4 pages.
Myerson, Judith. "Creating Applications with Amazon EC2 and S3." O'ReillyOnLamp.com, May 13, 2008 [Retrieved on Apr. 26, 2011]. Retrieved from the Internet /onlamp.com/pub/a/onlamp/2008/05/13/creating-applications-with-amazon-ec2-and-s3.html>, 8 pages.
'Nagios' [online]. "Monitoring Linux/Unix Machines," 2011, [retrieved on Feb. 3, 2011]. Retrieved from the Internet: nagios.sourceforge.net/docs/3-0/monitoring-linux.html > 1 page.
'Nagios' [online]. "Nagios Plugins," 2011, [retrieved on Feb. 3, 2011]. Retrieved from the Internet: agios.sourceforge.net/docs/3-0/plugins.html > 2 pages.
Paravirtualization, Wikipedia Article, downloaded from en.wikipedia.org/wiki/Paravirtualization on Mar. 18, 2012.
Paravirtualized File Systems, Eric Van Hensbergen, downloaded from slideshare.net/ericvh/9p-on-kvm on Mar. 18, 2012.
Uploading Personal ssh Keys to Amazon EC2, Eric Hammond, Oct. 14, 2010. Retrieved from the Internet: /alestic.com/2010/10/ec2-ssh-keys>, 3 pages.
Using and Managing AWS-Part 6: SSH Key Pairs, Top WordPress, May 26, 2009, Retrieved from the Internet:louddb.info/2009/05/26/using-and-managing-aws-part-6-ssh-key-pairs>, 5 pages.
Using and Managing AWS—Part 6: SSH Key Pairs, Top WordPress, May 26, 2009, Retrieved from the Internet:louddb.info/2009/05/26/using-and-managing-aws-part-6-ssh-key-pairs>, 5 pages.
VMCI Datagram API [Retrieved on Jun. 8, 2011], Retrieved from the Internet: pubs.vmware.com/vmci-sdk/datagram.html>, 1 page.
VMCI Overview [Retrieved on Jun. 8, 2011] Retrieved from the Internet: pubs.vmware.com/vmci-sdk/VMCI-intro.html>, 3 pages.
VMCI Overview [Retrieved on Jun. 8, 2011] Retrieved from the Internet: pubs.vmware.com/vmci-sdk/VMCI—intro.html>, 3 pages.
VMCIDs-Lookup [Retrieved on Jun. 8, 2011], Retrieved from the Internet: pubs.vmware.com/vmci-sdk/functions/VMCIDs-Lookup.html>, 2 pages.
VMCIDs—Lookup [Retrieved on Jun. 8, 2011], Retrieved from the Internet: pubs.vmware.com/vmci-sdk/functions/VMCIDs—Lookup.html>, 2 pages.
VMware vSphere [Retrieved on Jun. 8, 2011] Retrieved from the Internet: <URL: .vmware.com/products/vmotion/overview.html>, 2 pages.
Wikipedia, "Domain Name System". [online] [Retrieved on Feb. 4, 2012]. Retrieved from the Internet: <URL: http://en.wikipedia.org/wiki/Domain-Name-System>, 13 pages.
Wikipedia, "IPSec", [online] [retrieved on Jan. 4, 2011]. Retrieved from the Internet: en.wikipedia.org/wiki/IPsec/>, 8 pages.
Wikipedia, "Domain Name System". [online] [Retrieved on Feb. 4, 2012]. Retrieved from the Internet: <URL: http://en.wikipedia.org/wiki/Domain—Name—System>, 13 pages.
Wikipedia. "OAuth." [online] [Retrieved on Jan. 20, 2011]. Retrieved from the Internet <URL: en.wikipedia.org/wiki/OAuth> , 3 pages.
Wikipedia., Anycast [Retrieved on Oct. 10, 2011] Retrieved from the Internet: en.wikipedia.org/wiki/Anycast>, 5 pages.
'Zabbix' [online]. "Zabbix 1.8: The Ultimate Open Source Monitoring Solution," 2001-2012, [retrieved on Feb. 3, 2011]. Retrieved from the Internet: .zabbix.com/features.php.> 1 page.
Zhang et al. ("XenSocket: A high-throughput interdomain Transport for virtual machines", 2007, IBM T.J Watson research center, p. 184-203). *
CN104956376B (en) 2018-09-18 Virtualization methods and technology environment applications and device control
US20160335680A1 (en) 2016-11-17 Securing expandable display advertisements in a display advertising environment
CN103718198A (en) 2014-04-09 Predictive model application programming interface
CN101370010B (en) 2012-11-21 Method and apparatus for secure web browsing
CN107633171A (en) 2018-01-26 Device-tailored whitelists
US7856653B2 (en) 2010-12-21 Method and apparatus to protect policy state information during the life-time of virtual machines
EP2697996A1 (en) 2014-02-19 Server remotely executing an application using geographic location data of a mobile device
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BERRETH, FRANK;MOON, ERIC A.;HENRY, ROBERT R.;SIGNING DATES FROM 20120113 TO 20120214;REEL/FRAME:028195/0877