Injection Interrupts and Exceptions in Secure Virtual Machines

Abstract

According to one or more embodiments of the present invention, a computer-implemented method includes: initiating a secure entity by a non-secure entity executing on a host server, and prohibiting the non-secure entity from directly accessing any data of the secure entity. The method further includes injecting an interrupt generated by the host server into the secure entity. The injection includes adding, by the non-secure entity, information about the interrupt to a portion of a non-secure storage, and then associating the portion of the non-secure storage with the secure entity. The injection also includes controlling, by a secure interface of the host server, the injection of the interrupt into the secure entity.

Description

Background Art

[0001] This application relates to computer technology, and more particularly, to virtual machines or containers.

[0002] Cloud computing facilitates the ability to quickly and easily provision virtual machines to customers without the customers having to purchase hardware or provide floor space for physical servers. Customers can scale virtual machines up or down according to changing preferences. Typically, a cloud computing provider provisions virtual machines that physically reside at the provider's data center. In this environment, a customer's virtual machine runs as a client, and the cloud provider uses hypervisor code that runs as a host to virtualize server resources among multiple virtual machines that may belong to different customers.

[0003] Customers generally care about the security of data in virtual machines. A customer may expect security between its code, data, and the cloud computing provider, or between its data, code, and data and other virtual machines (VMs) running at the provider's site. A customer may expect security from the provider's administrators and protection against potential security vulnerabilities in other code running on the machine, including hypervisor code. These administrators and other code may be acting with malicious intent.

[0004] Generally, a virtual machine (VM) that runs as a client under the control of a hypervisor depends on the hypervisor to transparently provide virtualization services to the client. These services include memory management, instruction emulation, and interrupt handling. Summary of the Invention

[0005] According to one or more embodiments of the present invention, a computer-implemented method includes: initiating, by a non-secure entity executing on a host server, a secure entity and prohibiting the non-secure entity from directly accessing any data that the secure entity does not explicitly share. The method further includes injecting an interrupt generated by the host server into the secure entity. The injection includes adding, by the non-secure entity, information about the interrupt to a portion of a non-secure store associated with the secure entity. The injection also includes controlling, by a secure interface of the host server, the injection of the interrupt into the secure entity. In one or more examples, the secure entity is a secure virtual machine, a container, or a client. In one or more examples, the non-secure entity is a hypervisor, an OS, or a host.

[0006] According to one or more embodiments of the present invention, the method further includes, before the injection, determining, by the secure interface control, whether to allow the injection of the interrupt into the secure entity, wherein the injection is performed based on a determination to allow the injection of the interrupt into the secure entity. In one or more examples, the secure interface control determines that the interrupt is allowed to be injected into the secure entity based on a predetermined list of allowable interrupts for the secure entity. The list of permitted interrupts is specific to the secure entity.

[0007] According to one or more embodiments of the present invention, information regarding an interruption includes an identifier of the interruption to be injected and one or more parameters associated with the interruption. In one or more examples, the method further includes: before the injection, determining by the security interface control whether to allow the injection of the interruption and the one or more parameters into the security entity, wherein the injection is performed based on determining that the interruption and the one or more parameters are allowed to be injected into the security entity.

[0008] In one or more examples, the method further includes deallocating a processor associated with the security entity before injection by a non-secure entity. Further, after a non-secure entity adds information regarding an interruption, a virtual processor is reallocated to resume operation of the security entity.

[0009] According to one or more embodiments of the present invention, the method further includes: in response to determining that the interruption is not permitted to be injected into the security entity, instructing the security interface control to indicate an error to the non-secure entity.

[0010] According to one or more embodiments of the present invention, the security interface control includes hardware, microcode, and other trusted firmware.

[0011] In addition, according to one or more embodiments of the present invention, a computer-implemented method includes: being performed by a security entity executing on a non-secure entity on a host server, generating instructions for a condition to be forwarded to the non-secure entity, the non-secure entity being prohibited from directly accessing any data of the security entity that the security entity does not explicitly share. The method further includes de-dispatching the processor associated with the security entity executing the instructions, and then the non-secure entity emulating the instructions. The method also includes determining by the non-secure entity whether an interruption or a program exception should be delivered to the security entity, and based on such a determination, injecting an interruption or a program exception into the security entity in the non-secure entity. Injecting an interruption includes: based on an interruption or a program exception caused by emulation of the instructions, adding information regarding the interruption or the program exception by the non-secure entity to a portion of a non-secure storage device associated with the security entity. Injecting an interruption further includes resuming the processor associated with the security entity to resume operation of the security entity.

[0012] According to one or more embodiments of the present invention, the method further includes, before the injection, determining by the security interface control whether the program exception is valid for injecting the security entity, wherein the injection is performed based on determining that the program exception is valid for injecting the security entity. In one or more examples, the security interface control determines that the program exception is valid based on a predetermined exception list corresponding to the instruction. In one or more instances, the information about the program exception includes an identifier of the program exception to be injected and one or more parameters associated with the program exception.

[0013] The above features can also be provided by at least a system, a computer program product, and a machine.

[0014] Additional technical features and benefits are achieved through the technology of the present invention. Embodiments and aspects of the present invention are described in detail herein, and these embodiments and aspects are considered to be part of the claimed subject matter. For a better understanding, please refer to the detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The details of the exclusive rights described herein are particularly pointed out and clearly claimed in the claims of this specification. From the following detailed description in conjunction with the accompanying drawings, the foregoing and other features and advantages of the embodiments of the present invention are apparent, wherein:

[0016] Figure 1 A cloud computing environment according to an embodiment of the present invention is depicted;

[0017] Figure 2 An abstract model layer according to an embodiment of the present invention is depicted;

[0018] Figure 3 An example system for a host system according to an embodiment is shown;

[0019] Figure 4 An example block diagram of a host system is shown according to an embodiment;

[0020] Figure 5 A flowchart of an example method for security interface control to provide notification of an interrupt to a secure virtual machine (VM) according to one or more embodiments of the present invention is shown;

[0021] Figure 6 A flowchart of an example method for a secure virtual machine (VM) to cause an exception in a non-secure entity according to one or more embodiments of the present invention is shown. DETAILED DESCRIPTION

[0022] The different embodiments of the present invention are described herein with reference to the relevant drawings. Alternative embodiments of the present invention can be designed without departing from the scope of the present invention. Various connection and positional relationships (e.g., above, below, adjacent, etc.) are set forth between the elements in the following description and the drawings. Unless otherwise stated, these connections and / or positional relationships can be direct or indirect, and the present invention is not intended to be limited in this regard. Thus, the coupling of entities can refer to direct or indirect coupling, and the positional relationship between entities can be direct or indirect positional relationship. In addition, the various tasks and process steps described herein can be incorporated into a more comprehensive program or process having additional steps or functions not described in detail herein.

[0023] 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," or "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 series of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

[0024] Furthermore, 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 2, i.e., two, three, four, five, etc. The term "connected" can include both indirect "connection" and direct "connection."

[0025] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with a measurement of a specific quantity based on the equipment available at the time of filing the present application. For example, "about" can include a range of ±8% or 5%, or 2% of a given value.

[0026] For the sake of brevity, conventional techniques related to many aspects of the manufacture and use of the present invention may or may not be described in detail herein. Specifically, different aspects of the computing systems and specific computer programs for implementing the different technical features described herein are well known. Thus, for the sake of brevity, many conventional implementation details are only briefly mentioned herein or are omitted altogether without providing well-known system and / or process details.

[0027] A technical challenge with a typical cloud environment is the potential insecure and unwanted access to virtual machine (VM) data and algorithms (e.g., by a cloud provider or cloud administrator). Cloud providers typically run hypervisor code as the host, while the customer's virtual machines (VMs) run as guests. This hypervisor code provides the virtualization functionality required to allow multiple virtual machines (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 cases where it must access a limited portion of that data to provide the virtualization functionality. One example of virtualization is the hypervisor handling I / O operations. This is required due to the complexity of virtualizing I / O operations for a large number of virtualized clients. When a client issues an I / O instruction, such as I / O request x, to initiate a request, the first part of this virtualization begins. This requires the hypervisor to access the client machine operands (both registers and memory) of the I / O instruction. In response to the instruction, the hypervisor updates the appropriate control block structure to track the request and initiate an I / O request in the hardware. Those control block structures can be used by the hardware / firmware to present the associated I / O interrupt x directly to the client machine (if it is dispatched). However, if it enters an enabled wait state while waiting for the completion of the client's I / O request, since the client is not doing any work, the hypervisor can dispatch another client that does have work to do on the hardware. To do this, the hypervisor (with the help of the hardware / firmware) monitors when the I / O interrupt x becomes pending and, when applicable from a virtualization perspective, presents it to the client and reschedules the client. To do this, the hypervisor updates the client prefix page with the I / O interrupt information and updates the client instruction address to point to the client I / O interrupt handler before dispatching the client prefix page. This requires access to both the client storage and the client state (instruction address). To provide this and similar functionality, the hypervisor typically has unrestricted access to the client machine (VM) state and the storage in the machine, which as described herein can be insecure and untrusted and thus not desired by the customer. However, the hypervisor can be a non-secure entity, and the virtual machine (VM) is a secure entity. In one or more examples, the secure entity can also include a virtual container or a client. In one or more examples, the non-secure entity can also include an operating system instantiated within the virtual machine (VM). In one or more embodiments, the host 10 can also be considered a non-secure entity. Accordingly, one or more embodiments of the present invention provide for restricting the privileges of the hypervisor and also facilitating the completion of operations handled by the hypervisor, such as in the case of I / O operations, without authorizing access to the secure client facilities.

[0028] A virtual machine (VM) running as a client under the control of a hypervisor depends on the hypervisor to transparently provide virtualization services to the client. These services can include, but are not limited to, memory management, instruction emulation, and interrupt handling. The technical solutions provided by one or more embodiments of the present invention can be applied to any interface between a secure entity and another untrusted entity that traditionally allows this other entity to access secure resources. For example, for interrupt and exception emulation, the hypervisor typically reads and / or writes to the prefix area (low core) of the client. As used herein, the term "virtual machine" or "VM" 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 set of processors). From the perspective of a user or software resource, the virtual machine appears to be its own independent physical machine. As used herein, the terms "hypervisor" and "virtual machine monitor (VMM)" refer to a processing environment or platform service that manages and permits multiple virtual machines (VMs) to execute on the same host using multiple (and sometimes different) operating systems (OSs). It should be understood that deploying a virtual machine (VM) includes the installation process of the virtual machine (VM) and the activation (or startup) process of the virtual machine (VM). In another example, deploying a virtual machine (VM) includes the activation (or start) process of the virtual machine (VM) (e.g., in the case where the virtual machine (VM) has been previously installed or already exists).

[0029] In currently available technical solutions, the hypervisor (e.g., of Alternatively, an open-source software-based Kernel-based Virtual Machine (KVM) dispatches a new virtual machine (VM) virtual central processing unit (vCPU) on a physical processing unit or host server by issuing a Start Interpretation Execution (SIE) instruction that causes the SIE to enter microcode. The operand of the SIE instruction is a control block containing client state, called a State Description (SD). In existing implementations, this state description resides in hypervisor storage. During SIE entry, this client state (including general and control registers, client instruction address, and client program status word (PSW)) is loaded into hardware by microcode. This allows the guest vCPU to run on the physical processor. When the vCPU is running on the hardware, the client state is maintained in the hardware. At some point, the hardware / microcode must return control to the hypervisor. This is commonly referred to as SIE exit. For example, this may be necessary if the vCPU executes an instruction that needs to be emulated by the hypervisor or if the vCPU time slice (i.e., the time allocated for the vCPU to run on the physical processor) expires. During SIE exit, since the hardware has resources to support only a single vCPU at any given time and now must load the hypervisor state into the hardware, the microcode saves the current client state in the state description. Although the vCPU is not being scheduled, its state is maintained in the state description. Since the state description resides within hypervisor storage, in such cases, the hypervisor has control over the data of the virtual machine (VM), and in some cases, such control is required to emulate instructions executed on the virtual machine (VM). Existing hypervisors rely on using such an interface via the SIE instruction to dispatch vCPUs.

[0030] However, to facilitate secure clients, there are technical challenges where a computer server (such as a hosting node) must provide increased security between the hypervisor and the secure client such that the hypervisor cannot access data from the virtual machine (VM) and thus cannot provide services in the manner described above.

[0031] Some instructions (e.g., input / output (I / O) operations) are delegated to the hypervisor. Consequently, the hypervisor must perform the interpretation of those instructions, which may result in a client exception (program interruption) in many cases, such as when invalid parameters or operands are specified. This results in a situation where only the hypervisor knows which parameters or operands are valid and cannot directly present the exception (program interruption) to the secure client, i.e., the secure virtual machine (VM). Thus, a new interface is provided that allows the hypervisor to inject an interruption into the client via a secure interface control. Additionally, in some cases where the hypervisor monitors external or I / O interrupts on behalf of the secure virtual machine (VM), it must also be able to present the external or I / O interrupt to the virtual machine (VM).

[0032] The secure execution described herein provides a hardware mechanism to ensure isolation between secure and non-secure storage devices and between secure storage devices belonging to different secure users. For secure clients, additional security is provided between the "untrusted" non-secure hypervisor and the secure client. To do this, many of the functions that the hypervisor typically performs on behalf of the client need to be incorporated into the machine. A new secure interface control for providing a secure interface between the hypervisor and the secure client is described herein. The terms secure interface control and UV are used interchangeably herein. The secure interface control works in cooperation with the hardware to provide this additional security. Additionally, a lower-level hypervisor can provide virtualization for the untrusted hypervisor, and if the lower-level hypervisor is implemented in trusted code, it can also be part of the secure interface control.

[0033] In one example, the secure interface control is implemented in internal, secure, and trusted hardware and / or firmware. For a secure client or entity, the secure interface control provides the initialization and maintenance of the secure environment and the coordination of the dispatch of these secure entities on the hardware. When a secure client actively uses data and it resides in host storage, it remains "clean" in secure storage. The secure client storage can be accessed by that single secure client - this is strictly enforced by the hardware. That is, the hardware prevents any non-secure entity (including the hypervisor or other non-secure clients) or different secure clients from accessing the data. In this example, the secure interface control runs as the lowest-level trusted part of the firmware. The lowest level or microcode is effectively an extension of the hardware and is used to implement complex instructions and functions such as those defined in IBM's. The microcode is able to access all parts of the storage, which in the context of secure execution includes its own secure UV storage, non-secure hypervisor storage, secure client storage, and shared storage. The terms storage device and memory are used interchangeably herein. This allows it to provide any function that a secure client or hypervisor requires to support that client. The secure interface control also has direct access to the hardware, which allows the hardware to effectively provide security checks under the control of conditions established by the secure interface control.

[0034] One or more embodiments of the present invention address such technical challenges by providing new interfaces that allow the interrupt to be injected into a virtual machine (VM) by hardware or firmware. Further, one or more embodiments of the present invention provide such increased security while still allowing the hypervisor to provide services to the virtual machine (VM). This is accomplished by incorporating functions or portions of functions that access a secure client facility and are typically performed by the hypervisor on behalf of the client into a new "secure interface control". The injection method used by one or more embodiments of the present invention can be applied to any type of interrupt that the hypervisor may need to inject. In one or more examples, such functions can be provided by using microcode and / or other hardware modules, and in this specification, are collectively referred to as being provided by the secure interface control. Microcode is trusted firmware that acts as an extension of the processor hardware. Thus, one or more embodiments of the present invention facilitate the hypervisor in securely injecting an interrupt into a secure client and communicating via the secure interface control that an interrupt condition that must be processed by the client has occurred.

[0035] A brief description of the background art now follows, after which specific features used by one or more embodiments of the present invention for injecting interrupts and / or exceptions into a secure virtual machine (VM) by the hypervisor are described. It is understood in advance that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings recited herein is not limited to a cloud computing environment. Instead, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

[0036] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services, which can be rapidly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0037] The characteristics are as follows:

[0038] On-demand self-service: Cloud customers can unilaterally provision computing capabilities such as server time and network storage automatically as needed, without human interaction with the service provider.

[0039] Broad network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms such as mobile phones, laptops, and PDAs.

[0040] Resource Pool: The provider's computing resources are pooled to serve multiple customers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a meaning of location independence because customers generally have no control or knowledge of the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0041] Rapid Elasticity: Capabilities can be provided quickly and elastically (automatically in some cases) to scale out quickly and release quickly to scale in quickly. To the customer, the capabilities available for provisioning generally appear unlimited and can be purchased in any quantity at any time.

[0042] Measured Service: The cloud system automatically controls and optimizes resource use by leveraging metering capabilities at some level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource use can be monitored, controlled, and reported, providing transparency for both the provider and the customer of the utilized service.

[0043] The business model is as follows:

[0044] Software as a Service (SaaS): The capabilities provided to the customer are to use the provider's applications running on the cloud infrastructure. The applications can be accessed from different client devices through a thin client interface such as a web browser (e.g., web-based email). The customer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0045] Platform as a Service (PaaS): The capabilities provided to the customer are to deploy on the cloud infrastructure the customer-created or acquired applications created using the provider-supported programming languages and tools. The customer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but has control over the deployed applications and possibly the application hosting environment configuration.

[0046] Infrastructure as a Service (IaaS): The capabilities provided to the customer are to provide the processing, storage, networking, and other fundamental computing resources that the customer can deploy and run any software that may include operating systems and applications. The customer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over the selected networking components (e.g., host firewall).

[0047] The deployment model is as follows:

[0048] Private Cloud: The cloud infrastructure is operated only for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0049] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-premises or off-premises.

[0050] Public cloud: Makes cloud infrastructure available to the public or large industrial groups and is owned by an organization that sells cloud services.

[0051] Hybrid cloud: The cloud infrastructure is composed of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0052] The cloud computing environment is service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that includes a network of interconnected nodes.

[0053] Now refer to Figure 1 , which depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, and local computing devices used by cloud customers (such as a personal digital assistant (PDA) or mobile phone 54A, desktop computer 54B, laptop computer 54C, and / or in-vehicle computer system 54N) can communicate with the cloud computing nodes 10. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as the private cloud, community cloud, public cloud, or hybrid cloud or a combination thereof described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service where the cloud customer does not need to maintain resources on a local computing device. It should be understood that Figure 1 the types of computing devices 54A-N shown in are only illustrative, and the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device through any type of network and / or network addressable connection (e.g., using a web browser).

[0054] Now refer to Figure 2 , which shows a set of functional abstraction layers provided by the cloud computing environment 50 ( Figure 1 ). It should be understood in advance that Figure 2 the components, layers, and functions shown in are only illustrative, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0055] The hardware and software layer 60 includes hardware and software components. Examples of the hardware components include: a host 61; a server 62 based on the RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0056] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual machines 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0057] In one instance, the management layer 80 can provide the functions described below. Resource provisioning 81 provides for the dynamic acquisition of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing 82 provides cost tracking when resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources can include application software licenses. Security provides authentication for cloud customers and tasks, as well as protection for data and other resources. The user portal 83 provides access to the cloud computing environment for customers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that the required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides for the pre-arrangement and procurement of cloud computing resources based on the expected future requirements of the cloud computing resources according to the SLA.

[0058] The workload layer 90 provides examples of functions that can utilize the cloud computing environment. Examples of the workloads and functions that can be provided from this layer include: maps and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and source code versioning 96. It should be understood that these are merely some examples, and in other embodiments, the layer can include different services.

[0059] Figure 3Shows an example hosting node 10 according to one or more embodiments of the present invention. The hosting node 10 communicates directly or indirectly with one or more client devices 20A - 20C via a network 165. The hosting node 10 can be a data center or a host server of a cloud computing provider. The hosting node 10 executes a hypervisor 12, which facilitates the deployment of one or more virtual machines 15 (15A - 15N). The hosting node 10 also includes a hardware layer 13, which includes one or more hardware modules and microcode, and the microcode facilitates the hypervisor 12 to provide one or more services to the virtual machines 15 (including the security interface control 11). In prior art solutions, there is communication between the hypervisor 12 and the hardware / microcode 13; between the hardware / microcode 13 and one or more virtual machines (VMs) 15; between the hypervisor 12 and one or more virtual machines (VMs) 15; and between the hypervisor 12 through the hardware / microcode 13 to the virtual machine (VM) 15. To facilitate a secure virtual machine (VM) environment, the hosting node 10 according to one or more embodiments of the present invention does not include any direct communication between the hypervisor 12 and one or more virtual machines (VMs) 15, but provides communication through the security interface control 11.

[0060] For example, the hosting node 10 can facilitate the deployment of one or more of the virtual machines 15A - 15N by the client device 20A. The virtual machines 15A - 15N can be deployed in response to corresponding requests from different client devices 20A - 20C. For example, the virtual machine 15A can be deployed by the client device 20A, the virtual machine 15B can be deployed by the client device 20B, and the virtual machine 15C can be deployed by the client device 20C. The hosting node 10 can also facilitate client provisioning of a physical server (rather than running as a virtual machine). The embodiments described herein embody the provision of resources in the hosting node 10 as part of a 'virtual machine', however, the described technical solutions can be applied to providing resources as part of a physical server.

[0061] In an example, the client devices 20A - 20C can belong to the same entity, such as a person, an enterprise, a government agency, a department within a company, or any other entity, and the hosting node 10 can operate as a private cloud of the entity. In this case, the hosting node 10 only hosts the virtual machines 15A - 15N deployed by the client devices 20A - 20C belonging to the entity. In another example, the client devices 20A - 20C can belong to different entities. For example, a first entity can own the client device 20A, while a second entity can own the client device 20B. In this case, the hosting node 10 can operate as a public cloud hosting virtual machines from different entities. For example, the virtual machines 15A - 15N can be deployed in a shielded manner where the virtual machine 15A does not have easy access to the virtual machine 15B. For example, the hosting node 10 can use IBM z Processor Resource / System Manager (PR / SM) logical partition (LPAR) features to cover virtual machines 15A - 15N. These features (such as PR / SM LPAR) provide isolation between partitions, thus facilitating the hosting node 10 to deploy two or more virtual machines 15A - 15N for different entities on the same physical hosting node 10 in different logical partitions.

[0062] Client device 20A among client devices 20A - 20C is a communication device, such as a computer, smartphone, tablet computer, desktop computer, laptop computer, server computer, or any other communication device that requests the deployment of a virtual machine by the hypervisor 12 of the hosting node 10. Client device 20A can send requests received by the hypervisor via network 165 or directly. Virtual machine 15A among virtual machines 15A - 15N is a virtual machine image deployed by the hypervisor 12 in response to a request from client device 20A among client devices 20A - 20C. Hypervisor 12 is a Virtual Machine Monitor (VMM), which can 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 the hardware components of hosting node 10. With appropriate features and modifications, hypervisor 12 can be IBM z ORACLE VM SERVERTM, CITRIX XENSERVERTM, VMWARE ESXTM, MICROSOFT HYPER-VTM, KVM, or any other hypervisor. Hypervisor 12 can be a native hypervisor that executes directly on hosting node 10, or a hosted hypervisor that executes on another hypervisor.

[0063] Figure 4Shows components of an example hosting node in accordance with one or more embodiments of the present invention. The hosting node 10 can be a computer, such as a server computer, a desktop computer, a tablet computer, a smart phone, or any other computer that executes a hypervisor 12, which in turn deploys virtual machines 15A - 15N. The hosting node 10 includes components, which include hardware, such as electronic circuits. The hosting node 10 particularly 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. These devices 140 and 145 can include, for example, battery sensors, position sensors (altimeter 40, accelerometer 42, GPS 44), indicator / identification lights, etc. Input devices such as a conventional keyboard 150 and mouse 155 can be coupled to the I / O controller 135. The I / O controller 135 can be, for example, one or more buses or other wired or wireless connections, as known in the art. The I / O controller 135 can have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, which are omitted for simplicity, to enable communication.

[0064] The I / O devices 140, 145 can further include devices that transfer both input and output, such as, for example, disk and tape memories, network interface cards (NICs) or modulators / demodulators (for accessing other files, devices, systems, or networks), radio frequency (RF) or other transceivers, telephone interfaces, bridges, routers, etc.

[0065] The processor 105 is a hardware device for executing hardware instructions or software, particularly those stored in the memory 110. The processor 105 can be a custom or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the hosting node 10, a semiconductor - based microprocessor (in the form of a microchip or chipset), a macroprocessor, or other device for executing instructions. The processor 105 includes a cache 170, which can include, but is not limited to, an instruction cache for accelerating the fetching of executable instructions, a data cache for accelerating data extraction and storage, and a translation lookaside buffer (TLB) for accelerating the virtual - to - physical address translation of executable instructions and data. The cache 170 can be organized as a hierarchy of more cache levels (L1, L2, etc.).

[0066] Memory 110 may include one or a combination of volatile memory elements (e.g., random access memory, RAM, such as DRAM, SRAM, SDRAM) and non-volatile 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), magnetic tape, compact disc read-only memory (CD-ROM), disk, floppy disk, cassette tape, cartridge tape, etc.). Additionally, memory 110 may incorporate electronic, magnetic, optical, or other types of storage media. Note that memory 110 may have a distributed architecture, where different components are located remotely from each other but can be accessed by processor 105.

[0067] The instructions in memory 110 may include one or more separate programs, each program including an ordered list of executable instructions for implementing a logical function. In Figure 2 an example, the instructions in memory 110 include a suitable operating system (OS) for executing 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 an example such as the z SystemTM, the manufacturer of hosting node 10 may provide hypervisor 12. In the case of a system having a structure different from the z system, where hypervisor 12 is not provided by the hardware manufacturer, the provided cloud computing may use hypervisor 12, such as from VMWARETM, KVM, or other hypervisor providers. In an example, the administrator of physical hosting node 10 cannot modify hypervisor 12 unless it is necessary to apply services provided by the manufacturer. For example, hypervisor 12 may be provided as part of the "Licensed Internal Code (LIC)" and / or microcode of hosting node 10.

[0068] Additional data, including, for example, instructions or other retrievable information of processor 105, may be stored in storage device 120, which may be a storage device such as a hard disk drive or a solid-state drive. The stored instructions in memory 110 or storage device 120 may contain instructions enabling the processor to execute one or more aspects of the systems and methods of the present invention.

[0069] The managed node 10 may further include a display controller 125 coupled to a user interface or a display 130. In some embodiments, the display 130 may be an LCD screen. In other embodiments, the display 130 may include a plurality of LED status lights. In some embodiments, the managed node 10 may further include a network interface 160 for coupling to a network 165. The network 165 may be an IP-based network for communicating between the managed node 10 and external servers, clients, etc. via a broadband connection. In an embodiment, the network 165 may be a satellite network. The network 165 sends and receives data between the managed node 10 and an external system. In some embodiments, the 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 protocol. The network 165 may also be a packet-switched network, such as a local area network, a wide area network, a metropolitan area network, the Internet, or other similar types of network environments. The 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 systems, and may include devices for receiving and transmitting signals.

[0070] The client device 20A may request that the hypervisor 12 deploy a corresponding virtual machine 15A having access to specific hardware and / or software components of the managed node 10. For example, the client device 20A may request that the 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 specific hardware component, such as 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 specific type of processor, coprocessor, network card, or any other chip or electronic circuit. In an example, the client device 20A may use an identifier provided by the manufacturer of the electronic circuit to identify the electronic circuit. In an example, the identifier may be used in combination with a version identifier. Alternatively or additionally, the client device 20A may request that the virtual machine 15A have access to specific software components, such as 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. The client device 20A may use the corresponding unique identifier provided by the developer / manufacturer of the corresponding software component to identify the requested software component. In an example, the identifier may be used in combination with the version identifier of the software component.

[0071] Figure 5A flowchart showing an exemplary method by which a hypervisor controls the notification of interrupts provided to a secure virtual machine (VM) through a secure interface, according to one or more embodiments of the present invention. The method includes scheduling the secure virtual machine (VM) 15A vCPU and allocating the processor 105 and other computing resources to the secure virtual machine (VM) 15A by executing a SIE (Start Interpreter Execution) instruction. The SIE instruction places the processor 105 in an emulation state defined in a control block in the memory 110, which is commonly referred to as a state descriptor (SD). Typically, the SIE instruction has one operand that addresses the SD. That is, the SD contains fields that define the hardware state to be emulated on the (multiple) processors 105 as may be requested by the client device 20 for the secure virtual machine (VM) 15A. In one or more examples, the processor 105 may be considered a virtual processor because the processor 105 can be instructed to emulate the behavior of another processor architecture upon request of the client 20 that initiated the secure virtual machine (VM) 15A.

[0072] According to one or more embodiments of the present invention, the SD fields include: (1) a source field containing an absolute memory address at which the real address zero of the secure virtual machine (VM) (i.e., the client) is allocated, which locates the zero page of the client, (2) a field for the current PSW (Program Status Word) of the secure virtual machine (VM) 15A, (3) an area for saving the general registers (GRs) and control registers (CRs) of the secure virtual machine (VM) 15A, and (4) miscellaneous other fields for other client states.

[0073] The method includes the host 10 determining at 505 that an interrupt should be injected and creating the interrupt such that the interrupt can be injected into the secure virtual machine (VM) 15A. The interrupt can be an I / O, external interrupt, or any other type of interrupt. As previously mentioned, the hypervisor 12 cannot directly access the memory, registers, or any other data of the secure virtual machine (VM) 15A, preventing the hypervisor 12 from injecting the interrupt directly into the secure virtual machine (VM) 15A, as can be done in prior art solutions, i.e., the SD, prior to rescheduling.

[0074] At 510, if needed, the host 10 does not allocate a virtual processor to the secure virtual machine (VM) 15A that is to receive an interrupt. Further, at 515, the hypervisor 12 adds the interrupt to be injected and one or more parameters associated with the interrupt to the SD of the virtual processor. In one or more examples, this addition can alternatively be performed by the hypervisor 12 issuing an injection instruction in a typical manner, which is implemented by secure interface control. When identifying an instruction requested by the hypervisor 12, the secure interface control can inject an interrupt condition into the secure virtual machine (VM) 15A or securely add the interrupt information to the associated SD for processing at the next dispatch. At 520, the hypervisor 12 further resumes operation of the processor 105 allocated to the secure virtual machine (VM) 15A by reallocating the secure virtual machine.

[0075] At this time, when the hypervisor 12 reallocates a virtual processor for the secure virtual machine (VM) 15A, at 525, during the reallocation of the SIE entry for the vCPU, the secure interface control 11 checks whether the injected interrupt and its parameters are valid and checks whether the processor 105 is enabled for the type of interrupt being injected. When starting the secure virtual machine (VM) 15A, the client 20 or default settings can provide a list of interrupts that the secure virtual machine (VM) 15A can receive. In one or more examples, for security reasons, for example, a particular type of interrupt (e.g., an I / O interrupt) can be restricted from reaching the secure virtual machine (VM) 15A. Additionally, one or more types of parameters associated with the I / O interrupt can be restricted from reaching the secure virtual machine (VM) 15A. For example, parameters including text, memory pointers, or scripts to be executed by the secure virtual machine (VM) 15A or any other type of parameter can be restricted. In one or more examples, the secure interface control 11 has access to a list of interrupt types and / or parameter types that are restricted (or allowed) for the secure virtual machine (VM) 15A. For example, such a list can be stored in a secure portion of the memory allocated to the secure interface control 11. In one or more examples, different lists can be applied to different secure virtual machines (VMs).

[0076] If the verification of the interrupt type and parameter type is successful, then at 530 and 535, the secure interface control 11 injects the interrupt into the secure virtual machine (VM) 15A, and the execution of the secure virtual machine (VM) 15A resumes. The secure interface control 11 injects the interrupt by adding the information of the interrupt and the corresponding parameters to the memory (prefix page) and registers of the secure virtual machine (VM) 15A. Further, at 535, the execution of the secure virtual machine (VM) 15A resumes as the interrupt is triggered.

[0077] At 540, in the case where an incorrect value and / or parameter of an interrupt is verified by the security interface control 11, the security interface control 11 indicates an error, for example, via a validity interception to the hypervisor 12, and does not resume the execution of the secure virtual machine (VM) 15A. Upon receiving the validity interception, the security interface control 11 or the hypervisor 12 may issue an alert indicating a possible security vulnerability as described herein.

[0078] Accordingly, when the hypervisor 12 does not have direct access to the memory / register space associated with the secure virtual machine (VM) 15A, the above method facilitates the hypervisor 12 injecting an interrupt into the secure virtual machine (VM) 15A.

[0079] Furthermore, one or more embodiments of the present invention facilitate the secure virtual machine (VM) 15A causing an interrupt or a program exception to be triggered in the hypervisor 12.

[0080] When the secure virtual machine (VM) 15A executes a program instruction, for example, as part of an operation performed by an application executing in the secure virtual machine (VM) 15A, and if the program instruction requires interception by the hypervisor 12, there are technical challenges. The hypervisor 12 determines that there is a client exception associated with the program instruction as part of the emulation of that client program instruction, but cannot access any registers / memory associated with the secure virtual machine (VM) 15A, which are necessary for presenting the exception to the virtual machine (VM). One or more embodiments of the present invention described herein facilitate injecting an exception into the virtual machine (VM) 15A.

[0081] Figure 6 A flowchart of an exemplary method of a hypervisor causing an exception in a secure virtual machine (VM) in response to emulation of a client instruction in accordance with one or more embodiments of the present invention is shown. The method includes the secure virtual machine (VM) 15A issuing an instruction at 605 that requires hypervisor intervention. For example, the instruction may be a request for an I / O channel of the host 10, an instruction to enable asynchronous interrupts, or any other such instruction that requires the service of the hypervisor 12.

[0082] Conversely, in one or more embodiments of the present invention, at 610, the security interface control 11 presents instructions and other limited client state information to the hypervisor 12, for example, via a status descriptor. In one or more examples, the hardware or security interface control identifies that an instruction being executed by the secure virtual machine (VM) 15A requires the intervention of the hypervisor and, in response, intercepts the instruction. That is, it stops the virtual machine (VM) from executing the instruction and saves the current guest state in a secure storage device. The security interface control 11 securely exposes to the hypervisor 12 the portion of the client state required for instruction emulation, such as operands and opcodes, for example, by copying the information into the status descriptor, and begins executing the hypervisor code that processes the client interception. It should be noted that the instruction is accordingly passed for execution by the hypervisor 12 without any context from the secure virtual machine (VM) 15A. The security interface control 11 identifies the instruction to be intercepted based on a list of predetermined instructions (or instruction types) to be intercepted in this manner. At 615, the hypervisor 12 emulates the instruction.

[0083] At 620, the hypervisor 12 determines whether an exception is encountered during the emulation of the instruction. If no exception is encountered, then at 625, the hypervisor 12 resumes the execution of the secure virtual machine (VM) 15A. At 630, the secure virtual machine (VM) 15A resumes operation using the guest state accordingly, based on the status descriptor associated with the secure virtual machine (VM) 15A.

[0084] Conversely, if an exception is encountered during the emulation of the client instruction, then at 635, the hypervisor 12 determines which exception is to be presented to the secure virtual machine (VM) 15A. Thus, the hypervisor 12 includes, for example, information about the exception to be reported to the secure virtual machine (VM) 15A in the status descriptor. This information may include an identifier of the exception to be reported and one or more parameters corresponding to the exception to be reported. In one or more examples, the reported exception may be different from the exception actually encountered during the execution of the instruction. At 640, upon completion of the status descriptor update, the hypervisor 12 reallocates the secure virtual machine (VM) 15A using the SIE instruction. Alternatively, the hypervisor 12 may call the security interface control 11 via an instruction to indicate that an exception should be presented to the secure virtual machine (VM) 15A at the next dispatch, and the security interface control may make appropriate updates to the status descriptor or a similar control block.

[0085] During SIE entry, the security interface control 11 checks the status descriptor of the secure virtual machine (VM) 15A and identifies the exception information added by the hypervisor 12. At 645, the security interface control 11 determines whether to pass the exception to the secure virtual machine (VM) 15A. The security interface control 11 makes the determination based on a list of exceptions allowed to be passed to the secure virtual machine (VM) 15A. The exception list can be dedicated to the secure virtual machine (VM) 15A and can be a predefined list or a list provided by the client that initiated the secure virtual machine (VM) 15A, etc.

[0086] In addition, in one or more examples, the security interface control 11 checks whether the exception passed to the secure virtual machine (VM) 15A is appropriate based on the instructions passed to the hypervisor 12 for execution. For example, the security interface control 11 can have a list of guest instructions that can be intercepted to the hypervisor 12, and for each instruction, a set of one or more exceptions that can be passed back by the hypervisor 12 to the secure virtual machine (VM) 15A. If the exception being passed is not from the set of exceptions corresponding to the instruction being executed in the secure virtual machine (VM) 15A, then at 650, the security interface control 11 indicates an error by, for example, a validity interception such as issuing an alert as described herein.

[0087] Furthermore, at 645, the security interface control 11 determines the appropriateness of the exception passed to the secure virtual machine (VM) 15A by checking the parameters passed with the exception. If the parameters do not match one or more allowed parameter types, then at 650, the security interface control 11 issues an error condition or an alert.

[0088] Conversely, if the exception and parameters passed by the hypervisor 12 to the secure virtual machine (VM) 15A are valid, then at 655, the security interface control 11 injects the exception into the secure virtual machine (VM) 15A. Injecting the exception into the secure virtual machine (VM) 15A includes, for example, changing one or more register values and memory (low core) values of the secure virtual machine (VM) 15A that indicate to the operating system of the virtual machine (VM) 15A that an exception has occurred. At 630, the secure virtual machine (VM) execution is further resumed. Resuming includes the secure virtual machine (VM) 15A handling the exception raised due to the instruction that was being executed before being intercepted.

[0089] Accordingly, one or more embodiments of the present invention facilitate the injection of exceptions by the hypervisor 12 into the secure virtual machine (VM) 15A.

[0090] According to one or more embodiments of the present invention, a computer server may host a secure virtual machine (VM) that prohibits a hypervisor from accessing memory, registers, and other data associated with the secure virtual machine (VM), without having to modify the hypervisor and / or the secure virtual machine (VM) code / architecture to inject an interrupt into the hypervisor and / or an exception into the secure virtual machine (VM). Instead, according to one or more embodiments of the present invention, a secure interface control including nano-code uses status descriptors and a secure portion of memory / memories to facilitate such injection to convey interrupt / exception information. Further, the secure interface control performs a validity check on the interrupt / exception information to prevent malicious information from being passed between the secure virtual machine (VM) and the hypervisor, and in this way continues to maintain the security of the secure virtual machine (VM).

[0091] One or more embodiments of the present invention are rooted in computer technology, particularly virtual machines hosted by computer servers. Further, one or more embodiments of the present invention facilitate an improvement in the operation of computing technology itself (particularly virtual machines hosted by computer servers) by facilitating a computer server hosting a secure virtual machine (VM), where the hypervisor is prohibited from accessing memory, registers, and other such data associated with the secure virtual machine (VM). Additionally, one or more embodiments of the present invention facilitate the separation of the secure virtual machine (VM) from the hypervisor by using a hardware layer including nano-code and / or a secure interface control, and thus maintain the security of the virtual machine (VM) hosted by the computing server, providing an important step towards improving virtual machine (VM) hosting computing servers. The hardware layer provides lightweight intermediate operations to facilitate security without adding a large amount of overhead to inject interrupts and / or exceptions as described herein.

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

[0093] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage 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 disk, 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 mechanically encoded device (such as punched cards) or raised structures in grooves having instructions recorded thereon), and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0094] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device or downloaded 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 can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0095] The computer-readable program instructions for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, 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 may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform various aspects of the present invention.

[0096] 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 should 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.

[0097] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, which, when executed by the processor of the computer or other programmable data processing apparatus, creates a means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein includes an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0098] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices that render a series of operational steps executable on a computer, other programmable apparatus, or other devices to produce a computer-implemented process such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0099] The flowcharts 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 diagram may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the blocks 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 illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0100] The description of the 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 terms used herein were chosen to best explain the principles of the embodiments, the practical application, or the technical improvement of technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer - implemented method, comprising: Initiating, by a non - secure entity including a hypervisor executing on a host server, a secure entity including a secure virtual machine, and prohibiting the non - secure entity from directly accessing any data of the secure entity; Issuing, by the secure virtual machine, an instruction that requires intervention by the hypervisor; Controlling, by a security interface of the host server, intercepting the instruction by stopping the secure virtual machine from executing the instruction and saving the current guest state in a secure storage device of the host server, wherein the security interface control includes secure trusted hardware, secure trusted firmware, or a combination of secure trusted hardware and secure trusted firmware, wherein the security interface control runs as the lowest - level trusted part of the firmware on the host server, and wherein the security interface control provides coordination for the initialization and maintenance of a secure environment on the host server and the dispatching of the secure entity on the hardware; Exposing, by the security interface control, only a part of the guest state required for instruction emulation to the hypervisor and passing the instruction to the hypervisor for execution without any context from the secure virtual machine; Determining, by the hypervisor, that an exception is encountered during the emulation of the instruction; Determining, by the security interface control, based on the exception information provided by the hypervisor, whether to pass the exception to the secure virtual machine; And In response to determining to pass the exception, injecting, by the security interface control of the host server, the exception into the secure entity, and the non - secure entity is unable to provide direct communication including the exception to the secure entity.

2. The computer - implemented method according to claim 1, wherein the secure trusted firmware includes microcode that accesses all parts of the storage.

3. The computer - implemented method according to claim 1, further comprising: Before the injection, determining, by the security interface control, whether to allow injecting the exception into the secure entity, and wherein the injection is performed based on determining that the exception is allowed to be injected into the secure entity.

4. The computer - implemented method according to claim 3, wherein the security interface control determines that the exception is allowed to be injected into the secure entity based on a predetermined list of allowable exceptions of the secure entity.

5. The computer - implemented method according to claim 4, wherein the list of allowable exceptions is specific to the secure entity.

6. The computer - implemented method according to claim 3, the method further comprising, in response to determining that the exception is not permitted to be injected into the secure entity, indicating an error by the security interface control to the non - secure entity.

7. The computer-implemented method according to any one of claims 1 to 6, further comprising: Before the injection, determining, by the security interface control, whether to allow injecting the exception and one or more parameters into the secure entity, and wherein the injection is performed based on determining that the exception and the one or more parameters are allowed to be injected into the secure entity.

8. The computer-implemented method according to any one of claims 1 to 6, wherein, Adding the information about the exception includes one of the following: The non - secure entity stores the information about the exception into a status descriptor associated with the secure entity; And The non - secure entity issues an instruction to cause the secure interface control to store the information about the exception into a status descriptor associated with the secure entity.

9. A computer system, comprising: A memory; A secure interface control; And A processing unit, the processing unit being coupled to the memory and the secure interface control, the processing unit being configured to execute a non - secure entity including a hypervisor that hosts one or more secure entities including secure virtual machines, the non - secure entity being prohibited from directly accessing any data of the secure entities, and wherein the method executed by the processing unit comprises: The secure virtual machine issues an instruction that requires hypervisor intervention; The secure interface control of the host server intercepts the instruction by stopping the execution of the instruction by the secure virtual machine and saving the current guest state in a secure storage device of the host server, wherein the secure interface control comprises secure trusted hardware, secure trusted firmware, or a combination of secure trusted hardware and secure trusted firmware, wherein the secure interface control runs as the lowest - level trusted part of the firmware on the host server, and wherein the secure interface control provides the initialization and maintenance of the secure environment on the host server and the coordination of the dispatch of secure entities on the host server hardware; The secure interface control exposes only a portion of the guest state required for instruction emulation to the hypervisor and passes the instruction to the hypervisor for execution without any context from the secure virtual machine; The hypervisor determines that an exception is encountered during the emulation of the instruction; The secure interface control determines whether to pass the exception to the secure virtual machine based on the exception information provided by the hypervisor; and In response to determining to pass the exception, the secure interface control of the host server injects the exception into the secure entity, and the non - secure entity cannot provide direct communication including the exception to the secure entity.

10. The system according to claim 9, wherein After the non - secure entity adds the information about the exception, the virtual processor is re - allocated to resume the operation of the secure entity.

11. A computer program product comprising a computer - readable storage medium, the computer - readable storage medium including computer - executable instructions that, when executed by a processing unit, cause the processing unit to execute a method, the method comprising: A non - secure entity including a hypervisor executing on a host server initiates a secure entity including a secure virtual machine, and the non - secure entity is prohibited from directly accessing any data of the secure entity; The secure virtual machine issues an instruction that requires hypervisor intervention; The security interface control of the host server intercepts the instruction by stopping the execution of the instruction by the secure virtual machine and saving the current guest state in a secure storage device of the host server, where the security interface control includes secure trusted hardware, secure trusted firmware, or a combination of secure trusted hardware and secure trusted firmware, where the security interface control runs as the lowest-level trusted part of the firmware on the host server, and where the security interface control provides the initialization and maintenance of the secure environment on the host server and the coordination of the dispatching of the secure entities on the hardware; The security interface control exposes only the part of the guest state required for instruction emulation to the hypervisor and passes the instruction to the hypervisor for execution without any context from the secure virtual machine; The hypervisor determines that an exception is encountered during the emulation of the instruction; The security interface control determines whether to pass the exception to the secure virtual machine based on the exception information provided by the hypervisor; and In response to determining to pass the exception, the security interface control injects the exception into the secure entity, and the non-secure entity cannot provide direct communication including the exception to the secure entity.

12. The computer program product according to claim 11, wherein, The security interface control determines that the exception is allowed to be injected into the secure entity based on a predetermined list of allowable exceptions for the secure entity.

13. The computer program product according to claim 12, wherein, The method further includes: After the non-secure entity adds the information about the exception, reallocating the virtual processor to resume the operation of the secure entity.

14. The computer program product according to any one of claims 11 to 13, wherein, The information about the exception includes the identifier of the exception to be injected and one or more parameters associated with the exception.

Images