Dispatching of secure virtual machines

文档序号：144463 发布日期：2021-10-22 浏览：38次中文

阅读说明：本技术 安全虚拟机的分派 (Dispatching of secure virtual machines ) 是由 F·布萨巴 L·海勒于 2020-02-28 设计创作，主要内容包括：根据本发明的一个或多个实施例,一种计算机实现的方法包括由在主机服务器上执行的管理程序接收分派虚拟机的请求。该方法还包括基于确定虚拟机是安全虚拟机,通过由主机服务器的安全接口控件确定虚拟机的安全模式来阻止管理程序直接访问安全虚拟机的任何数据。基于安全模式是第一模式,安全接口控件从第一状态描述符加载虚拟机状态,第一状态描述符被存储在存储器的非安全部分中。基于安全模式是第二模式,安全接口控件从第二状态描述符加载虚拟机状态,第二状态描述符被存储在存储器的安全部分中。(In accordance with one or more embodiments of the invention, a computer-implemented method includes receiving, by a hypervisor executing on a host server, a request to dispatch a virtual machine. The method also includes preventing the hypervisor from directly accessing any data of the secure virtual machine by determining, by a secure interface control of the host server, a secure mode of the virtual machine based on determining that the virtual machine is a secure virtual machine. Based on the secure mode being the first mode, the secure interface control loads the virtual machine state from a first state descriptor, the first state descriptor being stored in the non-secure portion of the memory. Based on the secure mode being the second mode, the secure interface control loads the virtual machine state from a second state descriptor, the second state descriptor being stored in the secure portion of the memory.)

1. A computer-implemented method, comprising:

receiving, by a hypervisor executing on a host server, a request to dispatch a virtual machine;

based on determining that the virtual machine is a secure virtual machine, preventing the hypervisor from directly accessing any data of the secure virtual machine; and

executing, by a secure interface control of the host server:

determining a security mode of the virtual machine;

loading virtual machine state from a first state descriptor for the virtual machine based on the secure mode being a first mode, the first state descriptor stored in a non-secure portion of memory; and

loading the virtual machine state from a second state descriptor for the virtual machine based on the secure mode being a second mode, the second state descriptor stored in a secure portion of the memory.

2. The computer-implemented method of claim 1, wherein the second state descriptor is accessible only by the secure interface control and not by the hypervisor.

3. The computer-implemented method of claim 1 or 2, wherein the first state descriptor comprises a pointer to the second state descriptor.

4. The computer-implemented method of any of claims 1 to 3, wherein the secure interface control determines the secure mode of the virtual machine based on one or more secure interface controls authorized with a mask saved in the second state descriptor.

5. The computer-implemented method of any of claims 1 to 4, wherein the secure interface control verifies correctness of the virtual machine state by comparing values in the first state descriptor and the second state descriptor.

6. The computer-implemented method of any of claims 1 to 5, further comprising:

detecting an occurrence of an exit condition of the virtual machine; and

performing, by the secure interface control:

based on the secure mode being the first mode, storing the virtual machine state into the first state descriptor stored in the non-secure portion of the memory; and

based on the secure mode being the second mode, storing the virtual machine state into the second state descriptor stored in the secure portion of the memory.

7. The computer-implemented method of claim 6, further comprising:

based on the secure mode being a third mode, storing the virtual machine state into the second state descriptor stored in the secure portion of the memory, and storing one or more selected parameters from the virtual machine state into the first state descriptor stored in the non-secure portion of the memory.

8. The computer-implemented method of any of claims 1 to 7, wherein the secure interface control comprises millicode.

9. A system, comprising:

a memory;

a security interface control; and

a processing unit coupled with the memory and the secure interface control, the processing unit configured to execute a hypervisor that hosts a plurality of virtual machines, the hypervisor being prohibited from directly accessing any data of a secure virtual machine, and wherein the hypervisor is configured to perform a method of managing startup and retirement of the virtual machines, the method comprising:

receiving, by the hypervisor, a request to dispatch a virtual machine;

based on determining that the virtual machine is a secure virtual machine, preventing the hypervisor from directly accessing any data of the secure virtual machine; and

performing, by the secure interface control:

determining a security mode of the virtual machine;

10. The system of claim 9, wherein the second state descriptor is accessible only by the secure interface control and not by the hypervisor.

11. The system of claim 9 or 10, wherein the first state descriptor comprises a pointer to the second state descriptor.

12. The system of any of claims 9 to 11, wherein the secure interface control determines the secure mode of the virtual machine based on one or more secure interface controls authorized with a mask saved in the second state descriptor.

13. The system of any of claims 9 to 12, wherein the secure interface control verifies the virtual machine state by comparing values in the first state descriptor and the second state descriptor.

14. The system of any of claims 9 to 13, wherein the method further comprises:

detecting an occurrence of an exit condition of the virtual machine; and

performing, by the secure interface control:

based on the secure mode being the first mode, storing the virtual machine state into the first state descriptor stored in the non-secure portion of the memory; and

based on the secure mode being the second mode, storing the virtual machine state into the second state descriptor stored in the secure portion of the memory.

15. The system of claim 14, wherein the method further comprises:

16. A computer program product comprising a computer-readable storage medium including computer-executable instructions that, when executed by a processing unit, cause the processing unit to perform a method, the method comprising:

receiving, by a hypervisor executing on a host server, a request to dispatch a virtual machine;

based on determining that the virtual machine is a secure virtual machine, preventing the hypervisor from directly accessing any data of the secure virtual machine; and

executing, by a secure interface control of the host server:

determining a security mode of the virtual machine;

17. The computer program product of claim 16, wherein the second state descriptor is accessible only by the secure interface control and not by the hypervisor.

18. The computer program product of claim 16 or 17, wherein the first state descriptor comprises a pointer to the second state descriptor.

19. The computer program product of any of claims 16 to 18, wherein the method further comprises:

detecting an occurrence of an exit condition of the virtual machine; and

performing, by the secure interface control:

based on the secure mode being the first mode, storing the virtual machine state into the first state descriptor stored in the non-secure portion of the memory; and

based on the secure mode being the second mode, storing the virtual machine state into the second state descriptor stored in the secure portion of the memory.

20. The computer program product of claim 19, wherein the method further comprises:

21. A computer-implemented method, comprising:

dispatching a secure virtual machine by a hypervisor executing on a host machine, wherein the hypervisor is prevented from directly accessing any data of the secure virtual machine; and

based on the occurrence of the exit condition of the secure virtual machine, performing, by a secure interface control of a host server:

determining a security mode of the secure virtual machine;

based on the secure mode being a first mode, storing virtual machine state of the secure virtual machine into a first state descriptor, the first state descriptor stored in a non-secure portion of memory; and

based on the secure mode being a second mode, storing the virtual machine state into a second state descriptor stored in a secure portion of the memory that is not accessible by the hypervisor.

22. The computer-implemented method of claim 21, further comprising:

23. A system, comprising:

a memory;

a security interface control; and

dispatching a secure virtual machine by the hypervisor, the hypervisor being blocked from directly accessing any data of the secure virtual machine;

detecting an occurrence of an exit condition of the secure virtual machine; and

executing, by the secure interface control:

determining a security mode of the secure virtual machine;

based on the secure mode being a second mode, storing the virtual machine state into a second state descriptor stored in a secure portion of the memory that is not accessible by the hypervisor.

24. The system of claim 23, wherein the method further comprises:

25. The system of claim 23 or 24, wherein the secure interface control determines the secure mode of the secure virtual machine based on one or more secure interface controls authorized with a mask saved in the second state descriptor.

Background

The present application relates to computer technology, and more particularly, to virtual machines.

Cloud computing facilitates the ability to quickly and easily provision virtual machines for customers without requiring the customer to purchase hardware or provide ground space for physical servers. The guest may expand or contract the virtual machine according to the changed preferences. Typically, cloud computing providers provision virtual machines that physically reside at the provider's data center. In such an environment, a customer's virtual machine runs as a client, and the cloud provider uses hypervisor code running as a host to virtualize server resources between multiple virtual machines that may belong to different customers.

Customers are often concerned with the security of data in virtual machines. Cloud operators may not be trusted and customers may want to deploy their work without risk of being encumbered by malicious or incomplete code (e.g., hypervisors) and/or system administrators with the intent of maliciously operating a data center. Customers may desire security between their code and data and cloud computing providers, as well as security between their code and data and other VMs running at the provider's location, as well as security from the provider's administrator, as well as protection against potential security vulnerabilities in other code running on the machine. For example, a customer may request that cloud providers not have access to their data in order to reduce or avoid the possibility that cloud computing providers, such as U.S. (U.S.) corporation, may be forced to hand over confidential or proprietary documents through summons.

Disclosure of Invention

In accordance with one or more embodiments of the invention, a computer-implemented method includes receiving, by a hypervisor executing on a host server, a request to dispatch a virtual machine. The method further includes preventing the hypervisor from directly accessing any data of the secure virtual machine based on determining that the virtual machine is a secure virtual machine. The method also includes determining, by a secure interface control of the host server, a secure mode of the virtual machine. Further, based on the secure mode being the first mode, the secure interface control loads the virtual machine state from a first state descriptor for the virtual machine, the first state descriptor stored in the non-secure portion of the memory. Further, based on the secure mode being the second mode, the secure interface control loads the virtual machine state from a second state descriptor for the virtual machine, the second state descriptor stored in the secure portion of memory.

In one or more examples, the second state descriptor is accessible only by the secure interface control and not by the hypervisor. In one or more examples, the first state descriptor includes a pointer to the second state descriptor. In one or more examples, the secure interface control determines the secure mode of the virtual machine based on one or more secure interface controls authorized with a mask saved in the second state descriptor. Further, in one or more examples, the secure interface control verifies correctness of the virtual machine state by comparing values in the first state descriptor and the second state descriptor.

In accordance with one or more embodiments of the invention, the method further includes detecting an occurrence of an exit condition of the virtual machine, and based on the secure mode being the first mode, executing, by the secure interface control, the storing of the virtual machine state into a first state descriptor stored in the non-secure portion of the memory. The method also includes storing the virtual machine state in a second state descriptor stored in a secure portion of the memory based on the secure mode being the second mode.

In accordance with one or more embodiments of the present invention, the method further includes storing the virtual machine state in a second state descriptor stored in a secure portion of the memory and storing one or more selected parameters from the virtual machine state in a first state descriptor stored in a non-secure portion of the memory based on the secure mode being the third mode.

In one or more examples, the secure interface control comprises millicode (millicode).

In accordance with one or more embodiments of the invention, a computer-implemented method includes dispatching a secure virtual machine by a hypervisor executing on a host machine, wherein the hypervisor is prevented from directly accessing any data of the secure virtual machine. The method further includes determining, by a secure interface control of the host server, a secure mode of the secure virtual machine based on an occurrence of an exit condition of the secure virtual machine. Further, based on the secure mode being the first mode, the secure interface control stores the virtual machine state of the secure virtual machine into a first state descriptor, the first state descriptor being stored in a non-secure portion of the memory. Further, based on the secure mode being the second mode, the secure interface control stores the virtual machine state into a second state descriptor, the second state descriptor being stored in a secure portion of the memory that is not accessible by the hypervisor.

In one or more examples, based on the secure mode being the third mode, the method includes storing the virtual machine state into a second state descriptor stored in a secure portion of the memory, and storing one or more selected parameters from the virtual machine state into a first state descriptor stored in a non-secure portion of the memory. In one or more examples, the secure interface control determines the secure mode of the secure virtual machine based on one or more secure interface controls authorized with a mask saved in the second state descriptor.

The above-described features may also be provided at least by a system, a computer program product, and a machine.

Features described herein provide improvements to computer technology, and in particular to computer servers hosting Virtual Machines (VMs) by facilitating the hosting of secure VMs by the computer servers. In the case of a secure VM (the hypervisor is no longer trusted under control of VM data), dispatching the secure VM through the same hypervisor interface as in the existing computer server is still a preferred (or in some cases required) option for compatibility with the existing hypervisor to continue operation. Thus, one or more embodiments of the invention facilitate that hypervisor code does not have to be changed so that the same code (of an existing hypervisor) can be used to dispatch typical non-secure VMs as well as secure VMs that prohibit hypervisor data access in the host computer server.

Additional technical features and benefits are realized through the techniques of the present invention. Embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, reference is made to the detailed description and accompanying drawings.

Drawings

The details of the exclusive rights described herein are particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features and advantages of embodiments of the invention will become further apparent from the following detailed description, taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a cloud computing environment in accordance with one or more embodiments of the invention;

FIG. 2 illustrates abstraction model layers in accordance with one or more embodiments of the invention;

FIG. 3 shows a block diagram of a system in accordance with one or more embodiments of the invention;

FIG. 4 shows a block diagram of a hosting system in accordance with one or more embodiments of the invention;

FIG. 5 depicts a flowchart of an example method for a hypervisor to launch a secure virtual machine in accordance with one or more embodiments of the invention;

FIG. 6 illustrates an example structure of a state descriptor in accordance with one or more embodiments of the invention;

FIG. 7 illustrates an example structure of a state descriptor field in accordance with one or more embodiments of the invention; and

FIG. 8 illustrates a flow diagram of a method for facilitating exit of a secure virtual machine according to a selected secure mode in accordance with one or more embodiments of the invention.

Detailed Description

Various embodiments of the present invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be devised without departing from the scope thereof. In the following description and the drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are set forth between elements. These connections and/or positional relationships may be direct or indirect unless otherwise specified, and the invention is not intended to be limited in this respect. Thus, coupling of entities may refer to direct or indirect coupling, and positional relationships between entities may be direct or indirect positional relationships. Further, various tasks and process steps described herein may be incorporated into a more comprehensive procedure or process having additional steps or functionality not described in detail herein.

The following definitions and abbreviations are used to explain the claims and the specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," "containing," or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

Additionally, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" can be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "plurality" can be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connected" can include both indirect and direct "connections.

The terms "about," "substantially," "about," and variations thereof are intended to encompass the degree of error associated with measuring a particular quantity based on equipment available at the time of filing this application. For example, "about" may include a range of ± 8% or 5% or 2% of a given value.

For the sake of brevity, conventional techniques related to making and using aspects of the present invention may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs for implementing various features described herein are well known. Accordingly, for the sake of brevity, many conventional implementation details are only mentioned briefly herein or are omitted entirely, without providing well-known system and/or process details.

A technical challenge with typical cloud environments is potentially insecure and unwanted access to data and algorithms (e.g., by a cloud provider or cloud administrator). Cloud providers typically run hypervisor code as a host, while customers' VMs run as clients. The hypervisor code provides the virtualization functionality required to allow multiple VMs to run on a single physical machine. In existing systems, the hypervisor (and typically by extension, the cloud administrator) has access to the customer's data and algorithms for situations where it must access a limited portion of that data to provide virtualization functionality. The hypervisor is typically required to access the client data to interpret the client instructions and perform I/O operations on behalf of the client. Hypervisor access to the client memory is required for client functional correctness. Thus, one or more embodiments of the invention provide how to dispatch a secure VM using an untrusted hypervisor.

A virtual machine running as a guest under the control of a host hypervisor relies on the hypervisor to transparently provide virtualization services for the guest. These services may include, but are not limited to, memory management, instruction emulation, and interrupt handling. One or more embodiments of the present invention may be applied to any interface between a secure entity and another untrusted entity that traditionally allows the other entity to access secure resources. For example, for interrupt and exception emulation, the hypervisor typically reads and/or writes to the client's prefix region (low core). The term "virtual machine" or "VM" as used herein refers to a logical representation of a physical machine (computing device, processor, etc.) and its processing environment (operating system (OS), software resources, etc.). The virtual machine state is maintained by a hypervisor executing on the underlying host (physical processor or group of processors). From the perspective of a user or software resource, a VM appears to be a separate physical machine of its own. The terms "hypervisor" and "VM monitor (VMM)" are used herein to refer to a processing environment or platform service that manages and allows multiple VMs to execute using multiple (sometimes different) OSs on the same host machine. It should be understood that dispatching a VM includes: an installation process of the VM and an activation (or boot) process of the VM. In another example, dispatching a VM includes: the activation (or startup) process of the VM (e.g., where the VM was previously installed or already exists).

However, to facilitate a secure client, there are technical challenges in the case where a computer server, such as a managed node, must provide additional security between the hypervisor and the secure client, such that the hypervisor cannot access data from the VMs, and thus cannot provide services such as those described above.

In currently available solutions, a hypervisor (e.g.,is/are as followsOr open source software kernel based virtual machine (KVM)) dispatches a new VM virtual cpu (vcpu) on a physical processing unit or host server by issuing a SIE instruction that causes a Start Interpretive Execution (SIE) entry millicode to be invoked. Millicode is trusted firmware that operates as an extension of processor hardware. The operands of the SIE instruction are control blocks, called state descriptions, which contain the guest state. In existing implementations, the state description resides in the hypervisor store. During SIE entry, the guest state (including general purpose and control registers, guest instruction address, and guest Program Status Word (PSW)) is loaded into hardware by millicode. This allowsThe client vCPU is allowed to run on the physical processor. When the vCPU runs on hardware, the guest state is maintained in hardware. At some point, the hardware/microcode must return control to the hypervisor. This is commonly referred to as a SIE exit. Such processing may be required, for example, if the vCPU executes instructions that need to be emulated by the hypervisor, or if a vCPU time slice (i.e., the time allocated for the vCPU to run on a physical processor) expires. During the SIE exit, the millicode saves the current client state in the state description since the hardware has resources to support only a single vCPU at any given time and it must now load the hypervisor state into the hardware. When the vCPU is not dispatched, its state is maintained in the state description. Since the state description is located within the hypervisor store, in this case the hypervisor has control over the data of the VM, and in some cases such control is needed to interpret instructions executing on the VM. Existing hypervisors rely on dispatching vcpus through SIE instructions using such interfaces.

In the case of a secure VM (the hypervisor is no longer trusted under control of the VM data), dispatching the secure VM through the same hypervisor interface using the existing SIE instruction is still a preferred (or in some cases required) option for compatibility with existing hypervisors. One or more embodiments of the present invention address such technical challenges by facilitating limited changes to hypervisor code such that the same hypervisor infrastructure can be used to dispatch typical non-secure vcpus as well as secure vcpus that prohibit hypervisor data access. One or more embodiments of the invention facilitate existing hypervisors to launch secure vcpus using existing SIE instructions by using an underlying implementation of the improved SIE instructions in a secure interface control (e.g., millicode) that includes support for dispatching secure vcpus on hardware.

In one or more examples, such functionality may be provided through the use of millicode and/or other hardware modules, and in this specification, the hardware modules and millicode are collectively referred to as "security interface controls. Accordingly, one or more embodiments of the invention facilitate a hypervisor to safely and reliably use the same SIE interface to dispatch and de-dispatch (un-dispatch) a secure vCPU that is currently used to dispatch and de-dispatch a non-secure vCPU.

The background art is now briefly described below, followed by a description of particular features used by one or more embodiments of the invention for dispatching a secure VM by a hypervisor. It should be understood in advance that although this disclosure includes detailed descriptions regarding cloud computing, implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in connection with any other type of computing environment, whether now known or later developed.

Cloud computing is a model of service delivery for convenient, on-demand network access to a shared pool of configurable computing resources. Configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) can be deployed and released quickly with minimal administrative cost or interaction with the service provider. Such a cloud model may include at least five features, at least three service models, and at least four deployment models.

The characteristics are as follows:

self-service on demand: consumers of the cloud are able to unilaterally automatically deploy computing capabilities, such as server time and network storage, on demand without human interaction with the service provider.

Wide network access: computing power is obtained over a network and accessed through standard mechanisms that facilitate use through heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pool: the provider's computing resources are relegated to a resource pool to serve multiple consumers using a multi-tenant schema in which different physical and virtual resources are dynamically allocated and reallocated according to demand. Often the consumer has no control or knowledge of the exact location of the resources provided, but may be able to specify locations at higher levels of abstraction (e.g., country, state, or data center), and thus have location independence.

Quick elasticity: computing power can be deployed quickly, flexibly (and sometimes automatically) to scale up quickly, and can be released quickly to scale down quickly. The computing power available for deployment typically appears unlimited to the consumer and any amount of computing power is available at any time.

Measurable service: cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled and reported, providing transparency to the provider and consumer of the service used.

The service model is as follows:

software as a service (SaaS): the capability provided to the consumer is an application running on the cloud infrastructure using the provider. Applications may be accessed from various client devices through a thin client interface, such as a web browser (e.g., web-based email). Consumers neither manage nor control the underlying cloud infrastructure, including network, server, operating system, storage, and even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a service (PaaS): the ability to be provided to the consumer is to deploy consumer-created or acquired applications on the cloud infrastructure, which are created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but may control the deployed applications and possibly the application hosting environment configuration.

Infrastructure as a service (IaaS): the capability provided to the consumer is to deploy processing, storage, networking, and other underlying computing resources, where the consumer is able to deploy and run arbitrary software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

The deployment model is as follows:

private cloud: the cloud infrastructure operates solely for organization. It may be administered by an organization or a third party, and may exist inside or outside the organization.

Community cloud: the cloud infrastructure is shared by multiple organizations and supports specific communities with common interest relationships (e.g., mission missions, security requirements, policies, and compliance considerations). It may be managed by an organization or a third party and may exist within or outside the community.

Public cloud: the cloud infrastructure is provided to the public or large industry groups and is owned by the organization that sells cloud services.

Mixing cloud: the cloud infrastructure consists of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting traffic sharing technology for load balancing between clouds).

Cloud computing environments are service-oriented with features focused on stateless, low-coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that contains a network of interconnected nodes.

Referring now to FIG. 1, an illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 includes one or more cloud computing nodes 10 with which consumers of the cloud may communicate using local computing devices, such as Personal Digital Assistants (PDAs) or cellular telephones 54A, desktop computers 54B, laptop computers 54C, and/or automobile computer systems 54N. The nodes 10 may communicate with each other. They may be grouped physically or virtually in one or more networks (not shown), such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, as described above, or a combination thereof. In this way, the cloud consumer is able to allow the cloud computing environment 50 to provide infrastructure as a service, platform as a service, and/or software as a service without having to maintain resources on the local computing device. It should be understood that the types of computing devices 54A-N shown in fig. 1 are merely illustrative, and that computing node 10 and cloud computing environment 50 may communicate with any type of computing device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now to FIG. 2, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 6) is shown. It should be understood in advance that the components, layers, and functions shown in fig. 2 are merely illustrative and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

the hardware and software layer 60 includes hardware and software components. Examples of hardware components include host 61; a RISC (reduced instruction set computer) architecture based server 62; a server 63; a blade server 64; a storage device 65; networks and network components 66. In some embodiments, the software components include web application server software 67 and database software 68.

The virtual layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: the virtual machine 71; a virtual storage 72; virtual network 73 (including a virtual private network); virtual applications and operating systems 74; and virtual client 75.

In one example, the management layer 80 may provide the functionality described below. The resource provisioning function 81 provides for dynamic acquisition of computing resources and other resources for performing tasks within the cloud computing environment. The metering and pricing function 82 cost tracks the use of resources within the cloud computing environment and provides a bill or invoice for consuming the resources. In one example, these resources may include application software licenses. The security functions provide identity authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal function 83 provides consumers and system administrators access to the cloud computing environment. The service level management function 84 provides for the allocation and management of cloud computing resources to meet the required service level. A Service Level Agreement (SLA) planning and fulfillment function 85 provides prearrangement and provisioning for future demands on cloud computing resources as predicted by SLAs.

Workload layer 90 provides an example of the functionality that may utilize a cloud computing environment. Examples of workloads and functions that may be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education offers 93; data analysis processing 94; transaction processing 95; and source code versioning 96. It is to be understood that these are just some examples, and in other embodiments, the layers may include different services.

FIG. 3 illustrates an example hosting node 10 according to one or more embodiments of the invention. The hosting node 10 communicates with one or more client devices 20A-20C via a network 165. Further, client devices 20A-20C may communicate directly with hosting node 10, which hosting node 10 may be a data center or a host server of a cloud computing provider. The managed node 10 executes a hypervisor 12 that facilitates the deployment of one or more virtual machines 15 (15A-15N). The hosting node 10 further comprises a hardware layer or millicode layer 13 comprising a secure interface control 11. The secure interface control 11 comprises one or more hardware modules and microcode that facilitate the hypervisor 12 providing one or more services to the virtual machine 15, in prior art solutions, there is communication between the hypervisor 12 and the secure interface control 11; there is communication between the secure interface control 11 and one or more VMs 15; there is communication between the hypervisor 12 and one or more VMs 15; and there is communication from the hypervisor 12 to the VM15 through the secure interface control 11. To facilitate a secure VM environment, a managed node 10 according to one or more embodiments of the invention does not include any direct communication between the hypervisor 12 and one or more VMs 15.

For example, the hosting node 10 may facilitate the client device 20A to deploy one or more of the virtual machines 15A-15N. The virtual machines 15A-15N may be deployed in response to respective requests from different client devices 20A-20C. For example, virtual machine 15A may be deployed by client device 20A, virtual machine 15B may be deployed by client device 20B, and virtual machine 15C may be deployed by client device 20C. The hosting node 10 may also facilitate clients to provide physical servers (rather than running as virtual machines). The examples described herein embody resource provisioning in the hosting node 10 as part of a 'virtual machine', however, the described technical solution may be applied to provisioning resources as part of a physical server.

In one example, client devices 20A-20C may belong to the same entity, such as an individual, a business, a government agency, a department within a company, or any other entity, and hosting node 10 may operate as a private cloud of entities. In this case, the hosting node 10 separately hosts the virtual machines 15A-15N deployed by the client devices 20A-20C belonging to the entity. In another example, client devices 20A-20C may belong to different entities. For example, a first entity may own client device 20A, while a second entity may own client device 20B. In this case, the hosting node 10 may operate as a public cloud hosting virtual machines from different entities. For example, virtual machines 15A-15N may be deployed in a masked manner in which virtual machine 15A does not facilitate access to virtual machine 15B. For example, the hosting node 10 may use IBM zProcessor resource/system manager (PR/SM) Logical Partition (LPAR) features to overlay virtual machines 15A-15N. These features, such as PR/SM LPAR, provide isolation between partitions, facilitating the deployment of two or more virtual machines 15A-15N in different logical partitions for different entities on the same physical hosting node 10.

The client device 20A from the client devices 20A-20C is a communication device, such as a computer, smartphone, tablet, desktop computer, laptop computer, server computer, or any other communication device requesting deployment of a virtual machine by the hypervisor 12 of the hosting node 10. Client device 20A may send the request to be received by the hypervisor via network 165 or directly. Virtual machine 15A of virtual machines 15A-15N is a virtual machine image that hypervisor 12 deploys in response to requests from client device 20A of client devices 20A-20C. Hypervisor 12 is a Virtual Machine Monitor (VMM) which may be software, firmware, or hardware that creates and runs virtual machines. Hypervisor 12 facilitates virtual machine 15A to execute programs and/or store data using hardware components of managed node 10. With appropriate features and modifications, hypervisor 12 can be IBM zORACLE VM SERVER^TM、CITRIX XENSERVER^TM、VMWARE ESX^TM、MICROSOFT HYPER-V^TMOr any other management program. Hypervisor 12 may be a native hypervisor executing directly on managed node 10 or a managed hypervisor executing on another hypervisor.

FIG. 4 illustrates components of an example hosting node in accordance with one or more embodiments of the invention. The hosting node 10 may be a computer, such as a server computer, desktop computer, tablet computer, smartphone, or any other computer executing a hypervisor 12, which in turn deploys virtual machines 15A-15N. The managed node 10 comprises components that comprise hardware (e.g., electronic circuitry). Managed node 10 includes a processor 105, a memory 110 coupled to a memory controller 115, and one or more input devices 145 and/or output devices 140, such as peripheral or control devices communicatively coupled via a local I/O controller 135, among other components. These devices 140 and 145 may include, for example, battery sensors, position sensors (altimeter 40, accelerometer 42, GPS 44), indicators/identification lights, and the like. Input devices such as a conventional keyboard 150 and mouse 155 may be coupled to the I/O controller 135. I/O controller 135 may be, for example, one or more buses or other wired or wireless connections as is known in the art. The I/O controller 135 may have additional elements such as controllers, buffers (caches), drivers, repeaters, and receivers to enable communications, which are omitted for simplicity.

The I/O devices 140, 145 may also include devices that communicate with both input and output terminals, such as disk and tape storage, Network Interface Cards (NICs) or modulators/demodulators (for accessing other files, devices, systems, or networks), Radio Frequency (RF) or other transceivers, telephony interfaces, bridges, routers, and so forth.

The processor 105 is a hardware device for executing hardware instructions or software, particularly those stored in the memory 110. The processor 105 may be a custom made or commercially available processor, a Central Processing Unit (CPU), an auxiliary processor among multiple processors associated with the managed node 10, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or other means for executing instructions. Processor 105 includes a cache 170, which may include, but is not limited to, an instruction cache to accelerate executable instruction fetching, a data cache to accelerate data fetching and storing, and a Translation Lookaside Buffer (TLB) to accelerate virtual-to-physical address translations of both executable instructions and data. The caches 170 may be organized into a hierarchy of more cache levels (L1, L2, etc.).

The memory 110 may include one or a combination of the following: volatile memory elements (e.g., random access memory RAM, such as DRAM, SRAM, SDRAM) and nonvolatile memory elements (e.g., flash memory, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), tape, compact disc read-only memory (CD-ROM), magnetic disks, floppy disks, magnetic cassettes, cartridges, and the like). In addition, the memory 110 may incorporate electronic, magnetic, optical, or other types of storage media. Note that the memory 110 may have a distributed architecture, where various components are remote from each other, but may be accessed by the processor 105.

The instructions in memory 110 may comprise one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 2, the instructions in memory 110 comprise a suitable Operating System (OS) that executes hypervisor 12. The operating system may control the execution of other computer programs and provide scheduling, input-output control, file and data management, memory management, and communication control and related services. In examples such as the z-system, the manufacturer of the managed node 10 may provide the hypervisor 12, where the system has a different structure than the z-system, where the hypervisor 12 is not provided by the hardware manufacturer, the cloud computing provided may use the hypervisor 12 such as from the VMWARE or other hypervisor provider. In an example, an administrator of the physical hosting node 10 cannot modify the hypervisor 12 unless needed in order to apply the services provided by the manufacturer. For example, the hypervisor 12 may be provided as part of "licensed internal code" (LIC) and/or microcode for hosting the node 10.

Additional data (including, for example, instructions for processor 105 or other retrievable information) may be stored in storage 120, which may be a storage device such as a hard disk drive or solid state drive. The stored instructions in memory 110 or storage 120 may include instructions that enable a processor to perform one or more aspects of the systems and methods of the present disclosure.

The hosting node 10 may also include a display controller 125 coupled to a user interface or display 130. In some embodiments, display 130 may be an LCD screen. In other embodiments, display 130 may include a plurality of LED status lights. In some embodiments, the hosting node 10 may also include a network interface 160 for coupling to a network 165. Network 165 may be an IP-based network for communicating between host node 10 and external servers, clients, etc. via a broadband connection. In one embodiment, the network 165 may be a satellite network. The network 165 transmits and receives data between the managed node 10 and external systems. In some embodiments, network 165 may be a managed IP network managed by a service provider. The network 165 may be implemented wirelessly, for example, using wireless protocols and technologies such as WiFi, WiMax, satellite, or any other. The network 165 may also be a packet-switched network, such as a local area network, wide area network, metropolitan area network, the Internet, or other similar type of network environment. Network 165 may be a fixed wireless network, a wireless Local Area Network (LAN), a wireless Wide Area Network (WAN), a Personal Area Network (PAN), a Virtual Private Network (VPN), an intranet, or other suitable network system, and may include devices for receiving and transmitting signals.

Client device 20A may request hypervisor 12 to deploy a corresponding virtual machine 15A having access to particular hardware and/or software components of managed node 10, e.g., client device 20A may request that virtual machine 15A have access to a predetermined number of processors, a predetermined amount of volatile memory (e.g., Random Access Memory (RAM)), a predetermined amount of non-volatile memory (e.g., storage space), or any other hardware component. Alternatively or additionally, the client device 20A may request that the virtual machine 15A have access to a particular hardware component (e.g., an electronic circuit identified by a corresponding unique identifier). For example, the client device 20A may request that the virtual machine 15A have access to a particular type of processor, coprocessor, network card, or any other chip or electronic circuit. In one example, the client device 20A may identify the electronic circuit using an identifier provided by the manufacturer of the electronic circuit. In one example, the identifier may be used in conjunction with a version identifier. Alternatively or additionally, the client device 20A may request that the virtual machine 15A have access to a particular software component (e.g., an operating system, an application, a basic input/output system (BIOS), a boot image, or any other software component). The requested software components may include firmware and embedded programs in the hardware components of the managed node 10. Client device 20A may identify the requested software component using a respective unique identifier provided by the developer/manufacturer of the respective software component. In one example, the identifier may be used in conjunction with a version identifier of the software component.

As previously described, for virtual machine 15A to be a secure VM, all non-secure guests and hypervisor 12 are prohibited from accessing memory 110, storage 120, one or more portions of registers, and any other data associated with virtual machine 15A. In one or more examples, hypervisor 12 ensures that for any given resident secure guest page, the associated host absolute address can only be accessed through a single hypervisor (host) DAT mapping. That is, there is a single host virtual address that maps to any given host absolute address assigned to the secure VM 15A. Furthermore, the hypervisor DAT mapping (host virtual to host absolute) associated with any given secure guest page does not change when it is paged in. Furthermore, the host absolute page associated with any secure guest page is mapped for only a single secure guest. In addition, there is no sharing of memory/registers between the virtual machines 15, especially in the case of the secure VM 15A. Further, in one or more examples, hypervisor 12 assigns a secure portion of storage 120 to secure interface control 11. This secure portion of storage 120 is accessible to secure interface control 11 only after being allocated. After the contents of the secure portion are assigned to the secure interface control 11, none of the virtual machine 15 and/or the hypervisor 12 can access the contents of the secure portion.

Any attempted violation of these rules is prohibited by the secure interface control 11 and the escrow node 10, and an alarm may be raised. Alerts may be raised by sending notifications to one or more people, blocking operation of the hosting node 10, blocking requests from one or more client devices 20, blocking operation of the secure VM15 (and any other secure VM), and so forth.

FIG. 5 illustrates a flow diagram of an example method for a hypervisor to launch a secure VM in accordance with one or more embodiments of the invention. The method may include receiving a request from a client device 20A to boot a secure VM 15A at 501. In one or more examples, the request may be received from any other source, such as another VM 15B-15N, a computer application executed by the hypervisor 12, an administrator, and so forth.

The method includes creating a State Descriptor (SD) as an operand of a SIE (start interpretive execution) instruction at 505. The SD contains fields that define the secure vCPU state to be emulated on the processor 105 assigned to the secure VM, the vCPU state being based on the request of the client device 20A. In one or more examples, processor 105 may be considered a virtual processor in that processor 105 may be instructed to emulate the behavior of another processor architecture at the request of client 20 that originated secure VM 15A.

FIG. 6 depicts an example structure of an SD in accordance with one or more embodiments of the invention. In one or more examples, the same SD format is used for both the secure VM and the non-secure VM.

According to one or more embodiments of the invention, the State Descriptor (SD)600 includes a mode control field 602 that indicates whether the dispatched VM is secure or non-secure. In one or more examples, the mode control field 602 may be a bit.

Further, if the mode control field 602 indicates that the SD 600 is for a secure VM, the unique identification identifier 604 provides the secure guest domain ID for the particular secure VM 15A being dispatched. For a non-secure VM, the unique identifier 604 is not used and may include a default value, such as 0 (or any other value indicating that a field is not used).

Additionally, SD 600, referred to herein as the parent SD, includes pointers to secure SD blocks 608. The parent SD and its corresponding secure SD are referred to as a state description pair. The pointer to secure SD 608 includes a valid value in the case of a secure VM and is set to a null value in the case of a non-secure VM being dispatched. The valid pointer to secure SD 608 specifies the memory location of secure SD block 650. Secure SD module 650 resides in a portion of secure memory 110 that is allocated to be accessed only by secure interface control 11. Secure SD block 650 includes a pointer 658 back to parent SD 600. When the hypervisor 12 establishes the secure VM 15A, the secure portion of memory for the secure SD is donated/allocated to the secure interface control 11. The secure memory portion is accessible only by the secure interface control 11 and not by the hypervisor 12. It may additionally be tagged with an associated client domain ID. It should be noted that in other examples, the separation of content between secure and non-secure portions of memory may be performed in different ways.

In addition, SD 600 includes one or more SD fields 606. In one or more examples, where secure SD 650 is used, another set of SD fields 606 are also maintained in secure SD 650. SD field 606 from secure SD 650 is only accessible by secure interface control 11.

FIG. 7 depicts an example structure of an SD field according to one or more embodiments of the invention. In this context, the term "state descriptor" includes not only the state description itself, but also the satellite block, the pointers of which reside in the state description, used as an extension. As shown in fig. 7, SD field 606 may include VM General Register (GR)402, Access Register (AR)404, Control Register (CR)406, VM timer 408 (including clock comparators and CPU timers), VM prefix register 410, Logical Partition Number (LPN)432, Virtual CPU Number (VCN)412, Thread Validity Mask (TVM)430, Program Status Word (PSW), and Instruction Address (IA) 414. Additionally, it may include control information, such as an Intercept Control (IC) bit 420, to indicate whether certain instructions (e.g., a loader state word (LPSW) and Invalid Page Table Entry (IPTE)) require interception of the host. The SD field 606 shown is exemplary and may be different in one or more embodiments of the invention, including, for example, various other fields for other VM states.

Referring back to the flowchart of fig. 5, the hypervisor 12 issues a SIE instruction with SD 600 as an operand and execution of the instruction is completed by the secure interface control 11. The SIE (begin interpretive execution) instruction is used to boot up VM15 and allocate processor 105 and other computing resources to VM 15. At 510, the secure interface control 11 determines whether the VM to be dispatched is secure based on the mode control field 602 in the SD 600. If a non-secure VM is to be dispatched, as is done so far, then at 515, non-secure VM 15B is dispatched using SD field 606 from SD 600. The SIE instruction places the processor 105 in the emulation state defined in the SD.

Alternatively, if a secure VM is to be dispatched 510, the secure interface control 11 verifies the correctness of the secure VM at 520. This is performed by ensuring consistency of the various values stored in SD field 606 between the paired secure SD 650 and parent SD 600. In one or more examples, SD field 606 contains information to check for consistency (e.g., keys, handles). For example, the secure SD address is obtained from the non-secure, parent SD 600. The parent SD address (658) obtained from the paired secure state description (650) is expected to match the original SIE operand address (i.e., the pointer to non-secure SD 600). Other information, such as the domain ID, is also stored in the secure and non-secure SDs, and may be checked to ensure that the values in both are equal.

In the event that a secure VM is being dispatched and the consistency check between the parent, non-secure SD 600 and paired secure SD 650 fails, secure VM 15A state is deemed invalid, the dispatch is aborted and a corresponding notification, such as an audiovisual notification, message, or the like (not shown) is sent. With the correctness of the VM state verified at 520, the secure interface control 11 sets one or more bits in the hardware to configure the computing resources to be allocated to the secure VM 15A in a secure mode at 525.

Further, at 530, the secure guest domain ID 604 is loaded into hardware and other computing resources to establish a secure execution environment for the secure VM 15A. There may be different modes of the secure execution environment that generally provide varying restrictions on the hypervisor 12's access to the state of the secure VM 15A being dispatched. In one or more examples, such a mode facilitates debugging a workflow involving the secure VM 15A, although additional applications are possible in one or more embodiments of the invention.

For example, consider three debug secure modes of operation for the secure execution environment of secure VM 15A: transparent, translucent, and fully transparent modes. Transparent debug mode is used to allow hypervisor 12 to view only the registers of VM15 and not the secure memory associated with VM 15. In this mode, parent, non-secure SD 600 saves registers of VM15 and does not use secure SD 650 that would be used for authentication (520) in other modes. In semi-transparent mode, although the registers of VM15 are saved in secure SD 650, upon instruction interception or interruption of VM15, secure interface control 11 determines which register(s) are exposed to hypervisor 12 by copying the registers to non-secure parent SD 600. In non-transparent mode, the guest registers are not exposed to hypervisor 12 at all and are maintained only in secure SD 650.

At 535, the method (fig. 5) determines that the debug security mode selected based on the security interface control is controlled. The hardware controls that provide these modes of operation are masked by the debug mask field that is saved in secure SD 650, that is, secure SD 650 has information indicating which of the three debug modes is allowed. Secure interface control 11 is able to change the debug mask in secure SD 650 at runtime as needed. With the fully transparent mode selected, the SD field 606 from the non-secure SD 600 is used to dispatch the VM15 at 540. In this case, the hypervisor is allowed to access the full register state of the dispatched VM 15. With the semi-transparent mode or non-transparent mode selected, secure VM 15A is dispatched at 545 and 550, respectively, using SD field 606 from secure SD 650. The dispatched VM is then executed 560 until an exit condition is reached 565. The exit conditions may include instruction or interrupt interpretation, user request to exit the VM, and the like.

FIG. 8 illustrates a flow diagram of a method for facilitating exit of a secure VM according to a selected debug secure mode in accordance with one or more embodiments of the invention. At 801, the method starts after an exit condition of the VM occurs. At 805, the secure interface control 11 checks the debug security mode selected for the VM when it is dispatched.

With the fully transparent mode selected 805, the VM state is stored into the SD field 606 in the non-secure state description 600. That is, at 810, the VM is exited similar to an unsecure VM as is done in existing solutions. The computing resources associated with VM15 are configured in hypervisor mode by setting one or more parameters of computing resources 850. SD field 606 from SD 600 resides in non-secure memory and is accessible by hypervisor 12.

With non-transparent debug secure mode selected 805, VM15 is exited as a secure VM, and even after the VM exits, the hypervisor is unable to access any data/memory or other parameters of the VM state. Thus, at 820, the secure interface control 11 saves the VM state into the SD field 606 in the secure SD 650, which resides in the secure portion of memory 110 and is not accessible by the hypervisor 12. Further, at 822, the secure interface control 11 reconfigures the computing resources associated with the VM15 to operate in a non-secure mode.

With the semi-transparent debug secure mode selected, at 830, secure interface control 11 determines whether hypervisor assistance has been requested for completing the task associated with VM 15. Such assistance requests may be made, for example, when one or more values associated with VM15 are to be accessed via hypervisor 12 for debugging or any other such task. If hypervisor assistance is requested, secure interface control 11 determines at 832 what data associated with VM15 will be accessible to the hypervisor upon the exit of VM 15. In one or more examples, the assistance request includes an identification of which register(s) from the VM15 are to be accessible by the hypervisor 12. Alternatively, or additionally, the assistance request may include an identification of any other parameter from the VM state that will be accessible to the hypervisor 12 upon VM15 exit.

At 834, the secure interface control 11 stores the determined parameters/data from the VM state that the hypervisor 12 will have access to into the SD field 606 of the non-secure SD 600. Thus, since SD 600 resides in the non-secure portion of memory 110, hypervisor 12 may access the stored data. Further, at 820, the secure interface control 11 saves the VM state into the SD field 606 in the secure SD 650, which is in the secure portion of the memory 110 and is inaccessible by the hypervisor 12, and further, at 822, the secure interface control 11 reconfigures the computing resources associated with the VM15 to operate in a non-secure mode and loads the hypervisor state back into the hardware.

If a hypervisor assist request is not made (830), at 820, the secure interface control 11 saves the VM state into the SD field 606 in the secure SD 650 that is inaccessible to the hypervisor 12. Further, at 822, the secure interface control 11 reconfigures the computing resources associated with the VM15 to operate in the non-secure mode.

For all three debug security modes, after saving the VM state, at 850, the secure interface control 11 exits to the hypervisor 12 to continue further operation of the managed node 10.

Thus, one or more embodiments of the invention facilitate dispatching and exiting (de-dispatching) a VM as a secure VM or a non-secure VM, and also keep data secure from being accessed by the hypervisor and/or other VMs in the system.

In accordance with one or more embodiments of the invention, a computer server may host a secure VM that prohibits a hypervisor from accessing memory, registers, and other data associated with the secure VM without having to change the hypervisor and/or secure VM code/architecture to dispatch the secure VM. In contrast, in accordance with one or more embodiments of the present invention, a secure interface control comprising millicode facilitates protecting data using an improved structure of state descriptors and a secure portion of storage/memory. Further, the secure interface control stores data from the VM state based on the debug security mode, such that the secure interface control (millicode) can do so if one or more parameters are to be made accessible to the hypervisor.

One or more embodiments of the present invention are rooted in computer technology, in particular virtual machine hosting computer servers. Furthermore, one or more embodiments of the present invention facilitate improvements to the operation of the computing technology itself by facilitating a computer server hosting the VM to host the secure VM, particularly a virtual machine hosting a computer server, wherein even the hypervisor is prohibited from accessing memory, registers, and other such data associated with the secure VM. Furthermore, one or more embodiments of the present invention provide an important step towards improvements to VMs hosting a compute server by using a secure interface control that includes millicode to facilitate separation of secure VMs and hypervisors, and thus maintain the security of VMs hosted by the compute server. The secure interface control provides lightweight intermediate operations to facilitate security without adding substantial overhead to protect VM state during initialization/exit of the VM as described herein.

The present invention may be a system, method, and/or computer program product for any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions embodied thereon for causing a processor to perform various aspects of the present invention.

The computer readable storage medium may be a tangible device that can retain and store the instructions for use by the instruction execution apparatus. The computer readable storage medium may be, for example, but is not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device such as a punch card or a raised-in-groove structure having instructions recorded thereon, and any suitable combination of the foregoing. The computer-readable storage medium used herein should not be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses delivered through a fiber optic cable), or electrical signals transmitted through a wire.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing/processing device, or to an external computer or external storage device via a network (e.g., the internet, a local area network, a wide area network, and/or a wireless network). The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, an electronic circuit comprising, for example, a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), can personalize a custom electronic circuit by utilizing state information of computer-readable program instructions that the electronic circuit executes in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein comprise an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The description of various embodiments of the present invention has been presented for purposes of illustration but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, the practical application, or technical improvements to the techniques available on the market, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

27页详细技术资料下载

上一篇：一种医用注射器针头装配设备

下一篇：用于中断使能的安全接口控件高级指令拦截

Dispatching of secure virtual machines

相关技术

网友询问留言