Transparent Interpretation of Guest Instructions in a Secure Virtual Machine Environment

Abstract

A computer-implemented method is disclosed. The method includes executing an instruction stream by a virtual machine executing on a host server, wherein instructions from the instruction stream are to be intercepted by a hypervisor. 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 performing, by a security interface control of the host server, based on determining that the instruction cannot be interpreted by the security interface control itself: extracting one or more parameter data associated with the instruction from the secure virtual machine, and storing the parameter data in a buffer accessible by the hypervisor. The instruction is then intercepted into the hypervisor.

Description

Background Art

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

[0002] Cloud computing has facilitated the ability to quickly and easily provision virtual machines for 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, cloud computing providers provision virtual machines that physically reside at the provider's data center. In such an environment, the customer's virtual machines operate as clients, and the cloud provider uses hypervisor code operating 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 the data in their virtual machines. Cloud operators may not be trusted, and customers may want to deploy their work without the risk of being implicated by malicious or defective code such as a hypervisor and / or a system administrator with malicious intent to manipulate the data center. For example, a customer can request that the cloud provider not have access to their data in order to reduce or avoid the possibility that a cloud computing provider such as a U.S. company may be forced by subpoena to turn over confidential or proprietary documents. Summary of the Invention

[0004] According to one or more embodiments of the present invention, a computer-implemented method includes executing an instruction stream by a virtual machine executing on a host server, wherein instructions from the instruction stream are to be intercepted by a hypervisor. 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 further includes, based on determining that the instruction cannot be interpreted by the security interface control of the host server itself, the security interface control of the host server performing: extracting one or more parameter data associated with the instruction from the secure virtual machine, and storing the parameter data in a buffer accessible by the hypervisor. The instruction is then intercepted into the hypervisor.

[0005] According to one or more embodiments of the present invention, the method further includes, based on determining that the instruction can be interpreted by the security interface control of the host server itself, the security interface control of the host server performing: executing the instruction by the security interface control, and returning execution control to the secure virtual machine to continue executing the instruction stream.

[0006] According to one or more embodiments of the present invention, intercepting the instruction includes the security interface control setting a first flag indicating that the instruction is partially completed, and the security interface control setting a second flag indicating that the secure virtual machine is locked for execution.

[0007] According to one or more embodiments of the present invention, the method further includes determining that an instruction causes a program exception when executed based on a security interface control, presenting the exception to a security virtual machine instead of intercepting the instruction into a hypervisor.

[0008] According to one or more embodiments of the present invention, the method further includes, when the hypervisor finishes executing the instruction, updating, by a security interface control, the state of the security virtual machine with a response from the hypervisor, at least a part of the state being stored in a secure portion of a memory that cannot be accessed by the hypervisor.

[0009] According to one or more embodiments of the present invention, the hypervisor stores a response to the instruction in a dedicated buffer.

[0010] According to one or more embodiments of the present invention, the method further includes, upon completion of execution, intercepting, by a security interface control, an error condition into the hypervisor based on determining that a response generated by the hypervisor is invalid.

[0011] According to one or more embodiments of the present invention, the security interface control includes a millicode.

[0012] In addition, according to one or more embodiments of the present invention, the above features are provided by at least a system, a computer program product, and a machine.

[0013] According to one or more embodiments of the present invention, a computer-implemented method includes a hypervisor on a host machine executing guest instructions from a security virtual machine, the hypervisor being prohibited from directly accessing any data of the security virtual machine. The method further includes the hypervisor storing a response to the guest instructions in a predetermined buffer. The method further includes a security interface control of the host machine updating a state descriptor with the response by copying the response into a specified register in the state descriptor of the security virtual machine, the state descriptor being stored in a secure portion of a memory that cannot be accessed by the hypervisor.

[0014] According to one or more embodiments of the present invention, the method further includes intercepting, by a security interface control, an error condition into the hypervisor based on determining that a response generated by the hypervisor is invalid.

[0015] According to one or more embodiments of the present invention, the method further includes a security interface control resetting a first flag associated with the security virtual machine, the reset indicating that the security virtual machine can be dispatched to continue execution of an instruction stream.

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

[0017] The features described herein provide improvements to computer technology, particularly computer servers that host virtual machines (VMs) by facilitating the hosting of secure VMs. In the case of a secure VM, the hypervisor is no longer trusted under the control of the VM data and is even prohibited from accessing memory, registers, and other such data associated with the secure VM. Additionally, the technical features described herein facilitate the separation of the secure VM and the hypervisor by the host computer server, thereby maintaining the security of the VMs hosted by the computing server.

[0018] Additional technical features and benefits are realized through the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered to be part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

[0024] Figure 5 A flowchart of an example method for transparently interpreting client instructions in a secure virtual machine environment according to one or more embodiments of the present invention is shown; and

[0025] Figure 6 A flowchart of an example method for transparently interpreting client instructions in a secure virtual machine environment according to one or more embodiments of the present invention is shown. DETAILED DESCRIPTION

[0026] Various embodiments of the present invention are described herein with reference to the related drawings. Alternative embodiments of the present invention can be designed without departing from the scope of the present invention. In the following description and drawings, various connection and positional relationships (e.g., above, below, adjacent, etc.) are set forth between elements. Unless otherwise specified, 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 a direct or indirect positional relationship. In addition, the various tasks and process steps described herein can be incorporated into more comprehensive programs or processes having additional steps or functionality not detailed herein.

[0027] The following definitions and abbreviations are used to explain the claims and the specification. As used herein, the terms "comprising", "including", "having", "containing" or any other variation thereof are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or device 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 device.

[0028] 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 more preferred or advantageous than 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 "connection" and direct "connection".

[0029] The terms "about", "substantially", "approximately" and their variants are intended to include the degree of error associated with a particular quantity measurement 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.

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

[0031] A technical challenge with typical cloud environments is the potential for non-secure and unwanted access to data and algorithms (e.g., by cloud providers or cloud administrators). Cloud providers typically run hypervisor code as the host, with the customer's VMs running as guests. This hypervisor code provides the virtualization functionality needed 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 the virtualization functionality. For example, a cloud provider may dump memory to analyze performance and functionality issues in the system. The dumped memory may include customer secrets that the customer does not wish to expose. System operators are also able to display internal processor register states, which also exposes secrets. The hypervisor is required to access guest data, for example, to interpret guest instructions, and to perform I / O operations on behalf of the guest, among other reasons. Hypervisor access to guest memory is needed to provide guest functional correctness. In secure execution, as used in one or more embodiments of the present invention, the hypervisor is no longer trusted, but can still participate in guest instruction interpretation. Accordingly, one or more embodiments of the present invention provide a way for an untrusted hypervisor to securely emulate guest instructions.

[0032] Virtual machines that run as guests under the control of a host hypervisor rely on that hypervisor to transparently provide virtualization services for that guest. These services can include, but are not limited to, memory management, instruction emulation, and interrupt handling. 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 that other entity access to secure resources. For example, for interrupt and exception interpretation, the hypervisor typically reads and / or writes to the guest's prefix area (low core). 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 processor group). From the perspective of a user or software resource, the VM appears to be its own independent physical machine. The terms "hypervisor" and "VM monitor (VMM)" as used herein refer to a processing environment or platform service that manages and allows multiple VMs to execute on the same host using multiple (sometimes different) OSs. It should be understood that deploying a VM includes: the installation process of the VM and the activation (or startup) process of the VM. In another example, deploying a VM includes: the activation (or startup) process of the VM (e.g., in the case where the VM has been previously installed or already exists).

[0033] However, to promote secure clients, there are technical challenges in cases where a computing server such as a hosted node must provide additional security between the hypervisor and the secure client, such that the hypervisor cannot access data from the VM and thus cannot provide services in the manner described above.

[0034] In currently available technical solutions, a hypervisor (e.g., of or a virtual machine based on an open source software kernel (KVM)) dispatches a new VM virtual CPU (vCPU) on a physical processing unit or host server by issuing a SIE instruction that causes start interpretation execution (SIE) into the microcode to be invoked. The operand of the SIE instruction is a control block, called a state description (SD), which contains the client state. In existing implementations, this state description resides in the hypervisor storage. During SIE entry, this client state (including general registers and control registers, client instruction address, and client program status word (PSW)) is loaded into the hardware by the microcode. This allows the client 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 type of processing may be required 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 it now must load the hypervisor state into the hardware, the microcode saves the current client state in the state description. When the vCPU is not dispatched, its state is held in the state description. Since this state description is located within the hypervisor storage, in this case, the hypervisor has control over the data of the VM and, in some cases, this control is required to interpret instructions executed on the VM. Existing hypervisors rely on using such interfaces to dispatch vCPUs via SIE instructions.

[0035] In addition, a hypervisor that manages multiple VMs must interpret guest instructions, i.e., instructions executed on a VM. As part of such interpretation, in existing solutions, the hypervisor typically has full access to the SD and other data of the VM, where the SD and data are stored in a memory that is part of the host machine on which the hypervisor is executing. It should be noted that not all instructions executed on a VM need to be interpreted by the hypervisor. Generally, instructions that require system-level access (e.g., I / O access) need such hypervisor interpretation. Such guest instructions that require hypervisor interpretation result in a SIE exit intercept (interruption of the guest instruction stream) out of guest mode into the hypervisor. The hypervisor then checks which instruction caused the intercept and interprets it by reading and / or writing corresponding guest data present in guest registers or guest memory. Then, the intercepted VM is re-dispensed to continue executing its instruction stream.

[0036] It should be noted that generally, cases of "instruction interception" include the operating system of the VM issuing a CPUID instruction to identify hardware features, accessing machine-specific registers (MSRs), or directly accessing I / O ports. When such an instruction that needs to be intercepted is detected, control is immediately transferred to the hypervisor 12 for parsing. For example, if the VM issues an instruction to read or update a control register (CR) or machine-specific register (MSR) value, in some cases, this operation is intercepted and control is transferred to the hypervisor 12, where the behavior of the VM is simulated by the hypervisor, and the hypervisor needs to access one or more data values from the state descriptor of the VM. In addition, the intercepted operation can also include a host program exception, which is handled by the hypervisor 12.

[0037] In the case of a secure VM, when the hypervisor is no longer trusted under the control of the secure VM's data, the traditional interpretation of guest instructions is no longer possible. This technical challenge exists because the hypervisor cannot access guest data (registers and their memory). Even if the hypervisor is given limited access to the guest state, the hypervisor cannot observe the behavior of the secure VM to prevent or limit side-channel attacks. Therefore, the technical challenge for the hosting node is to facilitate secure interface controls and / or hypervisor interpretation and execution of guest instructions in a secure VM when the VM has limited "power" or "privilege" to access the system resources (e.g., I / O devices, etc.) of the hosting node.

[0038] According to one or more embodiments of the present invention, technical solutions are described to interpret instructions in a secure VM without exposing guest data to the hypervisor and without requiring rewriting of guest applications or the operating system. In other words, the interpretation of guest instructions by the millicode and the hypervisor is transparent to the secure VM itself. Thus, existing applications and operating systems can be used as is, and the hosting nodes and hypervisors that provide such secure VMs are compatible with existing products. In other words, one or more embodiments of the present invention address the technical challenge by facilitating that existing VMs, operating systems, and computer application code need not be changed and that this code can be used in hosting nodes and / or hypervisors that also dispatch VMs in a secure manner, thereby prohibiting the hypervisor from accessing the state and / or data of the secure VM. One or more embodiments of the present invention facilitate such technical solutions by using an improved underlying implementation of guest instruction interpretation in a secure interface control (such as millicode) that will interpret the guest instructions of the secure VM.

[0039] In one or more examples, such functionality can be provided by using millicode and / or other hardware modules, and in this description, the hardware modules and millicode are collectively referred to as "secure interface controls". Thus, one or more embodiments of the present invention facilitate the secure interpretation of instructions in a secure VM by an untrusted hypervisor by using secure interface controls (millicode and internal trusted hardware and firmware). The secure interface control coordinates the execution of instructions between the secure VM and the untrusted hypervisor. Guest instructions are intercepted as in an insecure VM, but control is not immediately given back to the hypervisor. Instead, control is first given to the secure interface control, which extracts the necessary guest data and passes it, along with the interception conditions of the guest instructions and additional context information, to the hypervisor. The hypervisor processes the request and returns a response to the secure interface control. The secure interface control then updates the guest state as needed depending on the intercepted instructions. Thus, the secure interface control isolates the hypervisor from the data of the secure VM, thereby enhancing the security of the data associated with the secure VM.

[0040] Now, the background art is briefly described below, and then specific features used by one or more embodiments of the present invention to inject interrupts and / or exceptions into a secure VM by the hypervisor are described. It should be understood in advance that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings described 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.

[0041] Cloud computing is a model for service delivery that enables convenient, on-demand network access to a shared pool of configurable computing resources. The configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) can be rapidly deployed and released with minimal management effort or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0042] The characteristics are as follows:

[0043] On-demand self-service: Consumers of the cloud can unilaterally and automatically deploy computing capabilities such as server time and network storage on demand without human interaction with the service provider.

[0044] Broad network access: Computing capabilities are obtained over the network and accessed through standard mechanisms that facilitate use via different types of thin client platforms or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0045] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated according to demand. Typically, consumers do not control or have knowledge of the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center), thus having location independence.

[0046] Rapid elasticity: Computing capabilities can be deployed rapidly and elastically (sometimes automatically) to scale out quickly and can be released rapidly to scale in quickly. To the consumer, the available computing capabilities for deployment generally appear to be infinite and can be obtained in any quantity at any time.

[0047] Measured service: The cloud system automatically controls and optimizes resource use 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 use can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

[0048] The service models are as follows:

[0049] Software as a Service (SaaS): The capability provided to the consumer is to use applications that the provider runs on the cloud infrastructure. The applications can be accessed from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer neither manages nor controls 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.

[0050] Platform as a Service (PaaS): The ability provided to the consumer is to deploy applications created or acquired by the consumer on a cloud infrastructure, which are created using programming languages and tools supported by the provider. The consumer neither manages nor controls the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly the application hosting environment configuration.

[0051] Infrastructure as a Service (IaaS): The ability provided to the consumer is to deploy processing, storage, networks, and other fundamental computing resources, where the consumer is able to deploy and run any software, which may include operating systems and applications. The consumer neither manages nor controls 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).

[0052] The deployment models are as follows:

[0053] Private cloud: The cloud infrastructure runs solely for an organization. It can be managed by the organization or a third party and can exist either inside or outside the organization.

[0054] Community cloud: The cloud infrastructure is shared by multiple organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by an organization or a third party and may exist either inside or outside the community.

[0055] Public cloud: The cloud infrastructure is provided to the public or a large industrial group and is owned by the organization selling the cloud services.

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

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

[0058] Now refer to Figure 1, depicts a schematic cloud computing environment 50. As shown, cloud computing environment 50 includes one or more cloud computing nodes 10 with which a consumer of the cloud can communicate using a local computing device, such as a personal digital assistant (PDA) or cellular phone 54A, desktop computer 54B, laptop computer 54C, and / or in-vehicle computer system 54N. Nodes 10 can communicate with one another. 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, as described above. In this way, a consumer of the cloud can allow cloud computing environment 50 to provide infrastructure as a service, platform as a service, and / or software as a service without maintaining resources on a local computing device. It should be understood that Figure 1 the types of computing devices 54A-N shown are merely illustrative, and computing nodes 10 and cloud computing environment 50 can communicate with any type of computing device via any type of network and / or network addressable connection (e.g., using a web browser).

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

[0060] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include hosts 61; servers 62 based on RISC (Reduced Instruction Set Computer) architecture; servers 63; blade servers 64; storage devices 65; networks and network components 66. In some embodiments, software components include web application server software 67 and database software 68.

[0061] 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.

[0062] In one example, the management layer 80 may provide the functions described below. The resource provisioning function 81 provides for the dynamic acquisition of computing resources and other resources for performing tasks within a cloud computing environment. The metering and pricing function 82 tracks the costs of resource usage within the cloud computing environment and provides a bill or invoice for consuming these resources. In one example, these resources may include application software licenses. The security function provides authentication for cloud consumers and tasks, and protection for data and other resources. The user portal function 83 provides access to the cloud computing environment for consumers and system administrators. The service level management function 84 provides the allocation and management of cloud computing resources to meet the required service levels. The service level agreement (SLA) planning and fulfillment function 85 provides advanced arrangement and provisioning for future requirements of cloud computing resources predicted according to the SLA.

[0063] The workload layer 90 provides examples of functions that can utilize the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; instructional delivery for virtual classrooms 93; data analysis processing 94; transaction processing 95; and source code versioning 96. It will be appreciated that these are merely some examples, and in other embodiments, these layers may include different services.

[0064] Figure 3 An example hosting node 10 in accordance with one or more embodiments of the present invention is shown. The hosting node 10 communicates with one or more client devices 20A - 20C via a network 165. Additionally, the client devices 20A - 20C may communicate directly with the hosting node 10, which may be a data center or host server of a cloud computing provider. The hosting node 10 executes a hypervisor 12 that facilitates the deployment of one or more virtual machines 15 (15A - 15N). The hosting node 10 also includes a security interface control 11 that includes one or more hardware modules and microcodes that facilitate the hypervisor 12 providing one or more services to the virtual machines 15. In prior art solutions, there is communication between the hypervisor 12 and the security interface control 11; there is communication between the security 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 VMs 15 through the security interface control 11. To facilitate a secure VM environment, the hosting node 10 in accordance with one or more embodiments of the present invention does not include any direct communication between the hypervisor 12 and one or more VMs 15.

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

[0066] In one example, the client devices 20A - 20C may belong to the same entity, such as an individual, an enterprise, a government agency, a department within a company, or any other entity, and the hosting node 10 may operate as a private cloud of the entity. In this case, the hosting node 10 individually 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 may belong to different entities. For example, a first entity may own the client device 20A, while a second entity may own the client device 20B. In this case, the hosting node 10 may operate as a public cloud hosting virtual machines from different entities. For example, the virtual machines 15A - 15N may be deployed in an obscured manner in which the virtual machine 15A does not facilitate access to the virtual machine 15B. For example, the hosting node 10 may use the IBM z Processor Resource / System Manager (PR / SM) Logical Partition (LPAR) features to overcommit the virtual machines 15A - 15N. These features, such as PR / SM LPAR, provide isolation between partitions, thereby 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.

[0067] 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. The client device 20A can send a request to be received by the hypervisor via the network 165 or directly. The virtual machine 15A among virtual machines 15A - 15N is a virtual machine image deployed by the hypervisor 12 in response to a request from the client device 20A among client devices 20A - 20C. The hypervisor 12 is a virtual machine monitor (VMM), which can be software, firmware, or hardware that creates and runs virtual machines. The hypervisor 12 facilitates the virtual machine 15A to execute programs and / or store data using the hardware components of the hosting node 10. With appropriate features and modifications, the hypervisor 12 can be IBM z ORACLE VM SERVER TM 、CITRIX XENSERVER TM 、VMWARE ESX TM 、MICROSOFT HYPER-V TM or any other hypervisor. The hypervisor 12 can be a native hypervisor that executes directly on the hosting node 10, or a hosted hypervisor that executes on another hypervisor.

[0068] Figure 4 illustrates the components of an example hosting node according to one or more embodiments of the present invention. The hosting node 10 can be a computer, such as a server computer, desktop computer, tablet computer, smartphone, or any other computer that executes the hypervisor 12, which in turn deploys the virtual machines 15A - 15N. The hosting node 10 includes components that contain hardware (such as electronic circuits). The hosting 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, and other components. 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 known in the art. The I / O controller 135 can have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communication, which are omitted for simplicity.

[0069] The I / O devices 140, 145 may also include devices that communicate with both the input and output sides, 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, telephone interfaces, bridges, routers, and the like.

[0070] 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 or commercially available processor, a central processing unit (CPU), an auxiliary processor among multiple processors associated with the hosting node 10, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macroprocessor, or other means for executing instructions. The processor 105 includes a cache 170, which may include, but is not limited to, an instruction cache that accelerates the extraction of executable instructions, a data cache that accelerates the extraction and storage of data, and a translation lookaside buffer (TLB) for accelerating the virtual-to-physical address translation of both executable instructions and data. The cache 170 may be organized as a hierarchy of more cache levels (L1, L2, etc.).

[0071] 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 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), magnetic disk, floppy disk, magnetic tape cartridge, cassette tape, etc.). In addition, the memory 110 may incorporate electrical, magnetic, optical, or other types of storage media. Note that the memory 110 may have a distributed architecture, where various components are located far from each other but are accessible by the processor 105.

[0072] The instructions in the 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 the memory 110 include an appropriate operating system (OS) for executing the hypervisor 12. This 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 System TM the manufacturer of the hosting node 10 may provide the hypervisor 12. In cases where the system has a structure different from that of the z System and the hypervisor 12 is not provided by the hardware manufacturer, the provided cloud computing may use, for example, those from VMWARE TMThe management program 12 or other management program providers. In the example, the administrator of the physical hosting node 10 cannot modify the management program 12 unless it is necessary to apply services provided by the manufacturer. For example, the management program 12 can be provided as part of the "Licensed Internal Code (LIC)" and / or microcode for the hosting node 10.

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

[0074] The hosting node 10 can also include a display controller 125 coupled to a user interface or a display 130. In some embodiments, the display 130 can be an LCD screen. In other embodiments, the display 130 can include a plurality of LED status lights. In some embodiments, the hosting node 10 can also include a network interface 160 for coupling to the network 165. The network 165 can be an IP-based network for communicating between the host node 10 and external servers, clients, etc. via a broadband connection. In one embodiment, the network 165 can be a satellite network. The network 165 sends and receives data between the hosting node 10 and external systems. In some embodiments, the network 165 can be a managed IP network managed by a service provider. The network 165 can be implemented wirelessly, for example, using wireless protocols and technologies such as WiFi, WiMax, satellite, or any other. The network 165 can 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 can 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 can include devices for receiving and transmitting signals.

[0075] The client device 20A may request the hypervisor 12 to deploy a corresponding virtual machine 15A with 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 (such as random access memory (RAM)), a predetermined amount of non-volatile memory (such as 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 one example, the client device 20A may use an identifier provided by the manufacturer of the electronic circuit to identify the electronic circuit. In one 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 one example, the identifier may be used in combination with the version identifier of the software component.

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

[0077] Any attempt to violate these rules is prohibited by the security interface control 11 and the managed node 10, and an alert can be issued. The alert can be triggered by sending notifications to one or more persons, blocking the operations of the managed node 10, blocking requests from one or more client devices 20, blocking the operations of the secure VM 15 (and any other secure VM), etc.

[0078] Figure 5 A flowchart illustrating an example method for a hypervisor to perform transparent interpretation of guest instructions from a secure VM according to one or more embodiments of the present invention is shown. The method may include receiving, at 501, a request from a client device 20A to start a secure VM 15A. In one or more examples, the request can be received from any other source, such as another VM 15B - 15N, a computer application executed by the hypervisor 12, an administrator, etc.

[0079] The method includes creating a non - secure state descriptor (SD) for the secure VM 15A. In one or more examples, the non - secure SD includes a reference to a secure SD, which is stored in a portion of the memory that is not accessible by the hypervisor 12 or other non - secure entities. For example, the security interface control 11 creates the secure SD and adds a reference to the secure SD in the non - secure SD. The secure SD may include: VM general registers (GRs), access registers (ARs), control registers (CRs), VM timers (including clock comparators and CPU timers), VM prefix registers, virtual CPU numbers (VCNs), program status words (PSWs), and instruction addresses (IAs). Additionally, the SD can include control information, such as intercept control (IC) bits, to indicate whether certain instructions (e.g., load program status word (LPSW), invalid page table entry (IPTE), etc.) need to intercept the host, or whether the VM translation lookaside buffer (TLB) needs to be cleared before VM instruction execution can begin. The above SD fields are exemplary and may be different in one or more embodiments of the present invention, for example, including various other fields for other VM states. In the case of a non - secure VM, the non - secure SD itself includes the above - mentioned fields / parameters that are described as part of the secure SD in the case of a secure VM.

[0080] The hypervisor 12 issues a SIE instruction, which takes the non-secure SD as an operand, and the execution of the instruction is handled by the secure interface control 11. The SIE (Start Interpreter Execution) instruction is used to dispatch the VM 15 and allocate the processor 105 and other computing resources to the VM 15. The SIE instruction places the processor 105 in the emulation state defined in the non-secure SD. In the case of a secure VM, the secure SD is accessed to initiate the dispatch of the secure VM 15A. In one or more examples, the non-secure SD includes an identifier to indicate whether the VM being dispatched is secure / non-secure, and thus, the secure interface control 11 accesses fields / parameters from the appropriate secure / non-secure portion of the memory.

[0081] The method further includes executing the guest instructions in the secure VM 15A at 505. At 510, the instruction stream in the secure VM 15A can continue to execute until an instruction that causes an interception condition is encountered. After the instruction causes an interception condition, at 510 and 515, the VM with the intercepted instruction determines whether the VM has been dispatched as a secure VM.

[0082] If the VM is dispatched as a non-secure VM, where the hypervisor 12 can access the data and / or memory associated with the VM, then at 520, the execution of the intercepted instruction continues as in the existing solution. The secure interface control determines whether it has been dispatched as a secure VM or a non-secure VM based on the status flag stored in the SD of the VM.

[0083] In the case where the VM is a non-secure VM, the execution of the instruction stream in the non-secure VM is paused, and control is transferred to the hypervisor 12, which accesses the data of the non-secure VM by directly accessing the SD of the non-secure VM to interpret the intercepted instruction. For example, the data used by the hypervisor 12 may include the values stored in the GR, CR, guest memory, and / or other registers of the non-secure VM. After the interpretation of the intercepted instruction is completed, the hypervisor 12 appropriately updates the guest state by storing one or more values as a response. For example, the hypervisor 12 directly stores these values into one or more registers of the non-secure VM by updating the values in the memory locations maintained in the SD of the non-secure VM. The hypervisor 12 may also update the guest memory as part of the instruction interpretation.

[0084] Alternatively, if the VM is the secure VM 15A, the secure interface control 11 is invoked at 525 to execute an intercept instruction. At 530, the secure interface control 11 determines whether the instruction should result in a suppressed or nullifying program exception due to execution. The secure interface control 11 simulates the execution of the intercept instruction to determine whether the execution will result in a program exception. For example, the instruction may request computing resources that are not available in the managed node 10. Alternatively or additionally, the intercept instruction may be an instruction that is not permitted at the privilege level at which the secure VM 15A is executing. Alternatively or additionally, the intercept instruction may violate a boundary condition during a memory access. The secure interface control 11 may check for any other type of program exception that would be caused by the execution of the intercept instruction. If an exception occurs due to the execution of the intercept instruction, then at 535, the secure interface control 11 presents the exception to the secure VM 15A.

[0085] In one or more examples, the instruction is suppressed or nullified depending on the type of program interruption. If a client exception suppression or nullification is applicable, the instruction interception does not reach the hypervisor 12. Instead, control is given directly to the interrupt handler of the secure VM 15A to handle the program exception. There is no reason to intercept the instruction to the hypervisor because the program exception must be handled first. For example, if the LCTLG instruction is to be intercepted and the stored operand provided to the instruction has a page fault, the program exception is given to the secure VM 15A to resolve the page fault first. After the page fault is resolved, the LCTLG is executed again, this time without a program exception. Thus, in subsequent executions, the features described herein are used to intercept the instruction to the hypervisor 12.

[0086] Some program exceptions are host-related. In such cases, an SIE exit is invoked and the program exception is provided to the hypervisor 12. For example, in the case of a host page fault, the hypervisor 12 maps the client page to the host absolute page and then re-dispenses the VM.

[0087] It should be noted that program exceptions can be nullification, suppression, and completion. The difference between suppression and nullification lies in the way the instruction address (IA) is updated. In a nullification exception, the IA points to the instruction that caused the exception, while in a suppression exception, the IA points to the next sequential instruction after the instruction with the exception. In both cases, no other updates are made to the client state or memory.

[0088] Alternatively, if the intercept instruction results in a completion exception, the secure interface control 11 at 537 detects and marks the completion exception flag of the intercept instruction. The completion exception (such as a program event record (PER)) is typically presented after the associated instruction is completed. In a non-secure VM environment, the hypervisor 12 detects such PER exceptions and presents them to the VM after the hypervisor 12 finishes interpreting the guest instruction. In a secure VM environment, the secure interface control 11 detects such PER program exceptions and marks them to be presented to the secure VM after the guest instruction finishes execution.

[0089] In addition, at 540, the secure interface control 11 checks which instruction is being intercepted. For example, the secure interface control 11 determines whether the instruction can be interpreted by the secure interface control 11 itself based on the instruction to be intercepted and, in some cases, one of the multiple operands of the instruction. Some operations such as writing to a guest control register that can enable a guest asynchronous interrupt (e.g., the LCTLG instruction) are typically done by the secure interface control and then intercepted, providing the hypervisor 12 with the minimally required guest state so that the hypervisor 12 can check whether any previously active but disabled guest interrupts are enabled. The hypervisor 12 then prioritizes the unhandled and enabled guest interrupts and securely presents the highest priority interrupt to the guest through the secure interface control. According to one or more embodiments of the present invention, in a secure VM environment, the secure interface control 11 interprets the LCTLG interpretation on behalf of the secure VM. Similarly, for intercepting the set prefix (SPX) instruction that returns to the hypervisor 12 for a non-secure VM, in one or more embodiments of the present invention, it will be interpreted by the secure interface control 11. If the operand is accessible by the secure interface control 11, the instruction can be considered interpretable by the secure interface control 11. If the instruction is interpretable by the secure interface control 11, the instruction execution is completed by the secure interface control 11 itself, and the instruction stream of the secure VM 15A is resumed at 545.

[0090] If the instruction is not interpretable by the secure interface control 11 itself, at 550, the secure interface control 11 sets the partial-completion flag associated with the guest instruction to a first state, e.g., partial-completion = 1. It should be understood that although the partial-completion flag is described in this application document as having a first state = 1 and a second state = 0, in one or more embodiments of the present invention, other values can be used for these two states.

[0091] In addition, at 552, the security interface control 11 sets the lock-VM flag associated with the secure VM 15A that includes the intercept instruction to a first state, e.g., lock-VM = 1. It can be understood that although the lock-VM flag is described in this application document as having a first state (e.g., = 1) and a second state (e.g., = 0), other values can be used for these two states in one or more embodiments of the present invention. The lock-VM flag indicates whether the secure VM 15A is "locked", i.e., whether the execution of the instruction stream is paused waiting for the completion of the instruction interpretation. The lock-VM flag also indicates whether the hypervisor response to the intercepted instruction forwarded by the security control interface to the secure VM 15A has been verified. In the example described herein, it is considered that in the first state (i.e., lock-VM = 1), the response to the secure VM 15A is to be verified, otherwise (i.e., lock-VM = 0), the response does not need to be verified at this time. The lock-VM also prevents the hypervisor 12 from accidentally or maliciously dispatching the secure VM without a response, and also prevents the hypervisor from attempting to inject an interrupt into the secure VM 15A before the instruction interpretation is completed. Thus, the lock-VM locks the secure VM 15A until it receives the response required for the guest instruction being interpreted.

[0092] When the secure VM 15A is in the locked state, it indicates to the security interface control 11 that the secure VM 15A is waiting for a response from the hypervisor 12 related to the instruction interpretation. In this case, the security interface control 11 prevents the secure VM 15A from being dispatched until the security interface control receives a valid response, in which case the state of the lock-VM flag is changed.

[0093] At 555, the security interface control 11 further intercepts the instruction for the hypervisor 12 to execute. The interception to the hypervisor 12 includes the security interface control 11 extracting one or more parameter data associated with the instruction from the secure portion of the memory and making it accessible to the hypervisor 12. The security interface control 11 can extract the parameter data from the secure VM 15A by examining the instruction, its operands, and its data. The operands and data can be stored in the hardware registers and memory associated with the secure VM 15A. In the SIE exit, the guest state is saved in the secure SD, and the intercept reason (and other hypervisor-related information) is saved in the non-secure SD. The physical processor on which the VM is running is now idle, and the hypervisor can re-dispatch the same VM or dispatch a new VM to the same physical processor. The lock-VM and other information related to the intercepted guest instruction are saved in the secure SD, thus allowing the VM to be dispatched to any available processor.

[0094] The security interface control 11 can make the extracted parameters accessible to the hypervisor 12 by creating a dedicated buffer for executing the specific instruction or using a dedicated buffer for executing such intercepted guest instructions. The security interface control 11 stores the data from the secure VM 15A (required by the hypervisor for instruction interpretation) in the dedicated buffer and passes the stored data as an operand / data to be used for interpreting the intercepted guest instruction to the hypervisor 12.

[0095] The hypervisor 12 generally does not know which instruction from the instruction stream in the secure VM 15A caused the interception - only knows the specific actions required on their part. At the time of interception, the hypervisor 12 is scheduled to perform instruction interpretation without any other context outside the context required for interpretation, such as the reason the instruction is being executed. Thus, at 560, the hypervisor 12 interprets the instruction without knowing the source / reason of the instruction.

[0096] Figure 6 A flowchart depicting a method for returning a response from the hypervisor to the secure VM after completion of the interpretation of intercepted secure VM instructions according to one or more embodiments of the present invention is shown. Upon completion of instruction interpretation, the hypervisor 12 dispatches the secure VM either without any interrupt injection (562) or with interrupt injection (564). The dispatch can be performed using the SIE instruction as described herein. As part of the secure VM dispatch operation, the guest state is read from the secure SD associated with the VM and loaded into the processor hardware (registers, memory, etc.). In one or more examples, the hypervisor 12 injects an interrupt into the VM via the security interface control 11 by storing interrupt parameter related information (such as identifiers and parameters) in a dedicated buffer. The security interface control 11 receives the execution control of the SIE call.

[0097] At 570, the security interface control 11 checks whether the lock-VM flag is set to 1. If lock-VM = 0 (or not equal to 1), then the security interface control 11 assumes that a different VM (without an intercepted instruction) is being dispatched by the called SIE instruction and thus, at 575, enters the different VM and initiates the execution of the instruction stream for that VM.

[0098] Alternatively, if Lock-VM = 1, i.e., the hypervisor 12 is returning execution control to the secure VM 15A that issued the intercepted instruction, then at 580, the secure interface control 11 checks whether a response to the instruction is received from the hypervisor 12. The secure interface control 11 makes the determination by checking a specified location in a dedicated buffer that is set for the hypervisor 12 to provide the instruction response. If no response is found, then at 582, the secure interface control 11 intercepts the hypervisor 12 with an error condition. If a response is provided in the dedicated buffer, then at 585, the secure interface control 11 ensures that the response is valid. If the response is invalid, then at 582, the secure interface control 11 intercepts the hypervisor 12 with an error condition.

[0099] In one or more examples, the secure interface control 11 ensures the validity of the response based on the type of response received from the hypervisor. For example, the provided response is valid for the type of intercepted instruction. Thus, for each intercepted instruction that is permitted, the secure interface control 11 has one or more permitted possible types of responses. For example, the secure interface control 11 checks that the data type of the response is valid from a list of expected response types for the intercepted instruction. For example, if the intercepted instruction is a request for an I / O operation, then the secure interface control 11 performs a check to verify that the response is a data type suitable for an I / O operation.

[0100] If it is determined that the response is valid, then the method continues, and at 590, the secure interface control 11 updates the state of the secure VM 15A based on the response from the hypervisor 12. Updating the state can include updating registers and memory associated with the secure VM 15A. Only the secure interface control 11 can access the SD of the secure VM 15A because it is stored in a secure portion of the memory that is accessible only by the secure interface control 11. Thus, the response remains secure and inaccessible from other VMs as well as the hypervisor 12.

[0101] In addition, at 592, the secure interface control 11 completes the execution of the intercepted guest instruction. Completing includes the secure interface control 11 updating the flag portion - complete and Lock-VM to a second state, i.e., setting portion - complete = 0 and Lock-VM = 0 for the secure VM 15A. At 595, the secure interface control 11 determines whether there is a corresponding completion exception associated with the intercepted instruction. If an exception exists, then the secure interface control 11 presents the completion exception to the secure VM 15A, which indicates that the secure VM 15A resumes its instruction stream being executed at 597 after processing the exception. Alternatively, if there is no program exception for the intercepted instruction, then the secure interface control 11 returns execution control to the secure VM 15A, which in turn resumes the instruction stream at 598.

[0102] Accordingly, one or more embodiments of the present invention facilitate the interpretation of guest instructions of a secure VM by a hypervisor in a host node. The guest instructions are intercepted normally (as in a non-secure VM), but control is not immediately given back to the hypervisor, but rather to a secure interface control. The secure interface control extracts guest data and passes it, along with the interception reason, to the hypervisor. The hypervisor processes the request and returns a response to the secure interface control.

[0103] The secure interface control checks for program exceptions including Program Event Records (PERs) and marks the guest instruction as partially completed before passing the request to the hypervisor. In the presence of an invalid or suppressed program interception, no signal is sent to the hypervisor and a program exception is taken. The secure interface control also checks and validates the hypervisor response before updating the guest instruction result. For a completion type program exception like a Program Event Record (PER), the secure interface control marks the instruction with a completed program exception, and upon return from the hypervisor, the secure interface control completes the instruction and forces a program interrupt.

[0104] Between the time the secure VM intercepts the hypervisor and the time of the hypervisor response, the secure interface control prevents the hypervisor from dispatching the same VM to any physical CPU. It also prevents the hypervisor from injecting interrupts (IO, external, or machine check) or exceptions (e.g., program exceptions) into the secure VM until the partially completed instruction is fully completed.

[0105] According to one or more embodiments of the present invention, a computer server can host a secure VM that prohibits the hypervisor from accessing memory, registers, and other data associated with the secure VM, without having to change the hypervisor and / or the secure VM code / architecture to intercept instructions to the hypervisor and / or inject responses into the secure VM. Instead, according to one or more embodiments of the present invention, a secure interface control including microcode uses an improved structure of state descriptors and a secure portion of a storage device / memory to facilitate protecting data. Additionally, the secure interface control stores data from the VM state such that in cases where the hypervisor is to be made accessible to one or more parameters, the secure interface control (microcode) can do so.

[0106] One or more embodiments of the present invention are rooted in computer technology, particularly virtual machine-hosting computer servers. Further, one or more embodiments of the present invention facilitate an improvement in the operation of computing technology itself by facilitating a computer server hosting a VM to host a secure VM, particularly a virtual machine-hosting computer server, where even the hypervisor is prohibited from accessing the memory, registers, and other such data associated with the secure VM. Additionally, one or more embodiments of the present invention provide an important step towards an improvement in the VM of a hosted computing server by using a secure interface control, the secure interface control including millicode to facilitate the separation of the secure VM and the hypervisor and thus maintain the security of the VM hosted by the computing server. The secure interface control provides lightweight intermediate operations to facilitate security without adding a substantial overhead of protecting the VM state during the initialization / exit of the VM as described herein.

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

[0108] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but is 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 a 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 mechanical encoding device such as a punched card or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium as used herein should not be construed as a transitory signal itself, 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 transmitted through an optical fiber cable) or an electrical signal transmitted through a wire.

[0109] The computer-readable program instructions described herein can be downloaded to a corresponding computing / processing device from a computer-readable storage medium 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.

[0110] The computer-readable program instructions for carrying out operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent 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 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, 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 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), can be customized by using the state information of the computer-readable program instructions, and the electronic circuit executes the computer-readable program instructions to perform aspects of the present invention.

[0111] 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 in 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.

[0112] These computer-readable program instructions can 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 executed by the processor of the computer or other programmable data processing apparatus create a means for implementing the functions / acts specified in the flowchart and / or one or more blocks of the 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 comprises an article of manufacture including instructions which implement various aspects of the functions / acts specified in the flowchart and / or one or more blocks of the block diagram.

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

[0114] 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, a segment of code, or a portion of an instruction, which comprises one or more executable instructions for implementing the specified logical function. In some alternative implementations, 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 should 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.

[0115] 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 have been 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 other ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method, comprising: An instruction stream is executed by a virtual machine running on a host server, where instructions from the instruction stream are to be intercepted by a hypervisor; Based on determining that the virtual machine is a secure virtual machine, prevent the hypervisor from directly accessing any data of the secure virtual machine; and Performed by a security interface control of the host server: Based on determining that the instruction cannot be interpreted by the security interface control itself: Extract, by the security interface control, one or more parameter data associated with the instruction from the secure virtual machine; Store, by the security interface control, the one or more parameter data into a buffer accessible by the hypervisor; and Intercept, by the security interface control, the instruction into the hypervisor.

2. The computer-implemented method according to claim 1, wherein, Based on determining that the instruction can be interpreted by the security interface control itself: Execute, by the security interface control, the instruction; And Return execution control to the secure virtual machine to continue executing the instruction stream.

3. The computer-implemented method according to claim 1, wherein, Intercepting the instruction further includes: Set, by the security interface control, a first flag indicating that the instruction is partially completed; and Set, by the security interface control, a second flag indicating that the secure virtual machine is in an execution locked state.

4. The computer-implemented method according to claim 3, wherein, The security interface control prevents dispatching of the secure virtual machine in the locked state, where the locked state indicates that the secure virtual machine is waiting for a response from the hypervisor.

5. The computer-implemented method according to any one of claims 1 to 4, further comprising: Based on the security interface control determining that the instruction causes a program exception when executed, present the exception to the secure virtual machine.

6. The computer-implemented method according to any one of claims 1 to 4, further comprising: Upon completion of the hypervisor's execution of the instruction, use, by the security interface control, the response from the hypervisor to update the state of the secure virtual machine, where at least a portion of the state is stored in a secure portion of a memory that cannot be accessed by the hypervisor.

7. The computer-implemented method according to claim 6, wherein, The hypervisor stores the response to the instruction in a dedicated buffer.

8. The computer-implemented method according to claim 6, further comprising: Upon completion of the execution, based on determining that the response generated by the hypervisor is invalid, intercept, by the security interface control, an error condition to the hypervisor.

9. A computer system, comprising: Memory; Security interface control; And A processing unit coupled to the memory and the security interface control, the processing unit configured to execute a hypervisor that hosts multiple virtual machines, the hypervisor being prohibited from directly accessing any data of a secure virtual machine, and where the hypervisor is configured to execute a method for interpreting one or more guest instructions from the virtual machines, the method including: Execute, by a virtual machine, an instruction stream, where instructions from the instruction stream are to be intercepted by a hypervisor; Determine that the virtual machine is a secure virtual machine; and Performed by the security interface control: Based on determining that the instruction cannot be interpreted by the security interface control itself: Extract, by the security interface control, one or more parameter data associated with the instruction from the secure virtual machine; Store, by the security interface control, the one or more parameter data into a buffer accessible by the hypervisor; and Intercept, by the security interface control, the instruction into the hypervisor.

10. The system according to claim 9, wherein, Based on determining that the instruction can be interpreted by the security interface control itself: Execute the instruction by the security interface control; and Return the execution control to the security virtual machine to continue executing the instruction stream.

11. The system according to claim 9, wherein, Intercepting the instruction further includes: Setting a first flag by the security interface control, the first flag indicating that the instruction is partially completed; and Setting a second flag by the security interface control, the second flag indicating that the security virtual machine is locked for execution.

12. The system according to any one of claims 9 to 11, wherein, The method further includes: Based on the security interface control determining that the instruction causes a program exception when executed, presenting the exception to the security virtual machine.

13. The system according to any one of claims 9 to 11, wherein, The method further includes: When the hypervisor finishes executing the instruction, using the response from the hypervisor by the security interface control to update the state of the security virtual machine, at least a part of the state being stored in a secure portion of the memory that cannot be accessed by the hypervisor.

14. The system according to claim 13, wherein, The hypervisor stores the response to the instruction in a dedicated buffer.

15. The system according to claim 13, wherein, The method further includes: When the execution is completed, based on determining that the response generated by the hypervisor is invalid, intercepting an error condition to the hypervisor by the security interface control.

16. A computer program product comprising computer-executable instructions which, when executed by a processing unit, cause the processing unit to execute a method, the method comprising: Execute an instruction stream by a virtual machine executing on a host server, wherein an instruction from the instruction stream is to be intercepted to the hypervisor; Determine that the virtual machine is a security virtual machine, the hypervisor being prevented from directly accessing any data of the security virtual machine; and Execute by the security interface control of the host server: Based on determining that the instruction cannot be interpreted by the security interface control itself: Extract one or more parameter data associated with the instruction from the security virtual machine by the security interface control; Store the one or more parameter data in a buffer that can be accessed by the hypervisor by the security interface control; and Intercept the instruction into the hypervisor by the security interface control.

17. The computer program product according to claim 16, wherein, Based on determining that the instruction can be interpreted by the security interface control itself: Execute the instruction by the security interface control; and Return the execution control to the security virtual machine to continue executing the instruction stream.

18. The computer program product according to claim 16 or 17, wherein, The method further includes: When the hypervisor finishes executing the instruction, using the response from the hypervisor by the security interface control to update the state of the security virtual machine, at least a part of the state being stored in a secure portion of the memory that cannot be accessed by the hypervisor.

19. The computer program product according to claim 18, wherein, The hypervisor stores the response to the instruction in a dedicated buffer.

20. The computer program product according to claim 18, wherein, The method further includes: When the execution is completed, based on determining that the response generated by the hypervisor is invalid, intercepting an error condition to the hypervisor by the security interface control.

21. A computer-implemented method, comprising: Execute client instructions from a security virtual machine by a hypervisor on a host machine, the hypervisor being prohibited from directly accessing any data of the security virtual machine; The hypervisor stores the response to the client instruction in a predetermined buffer; And The security interface control of the host machine updates the state descriptor with the response by copying the response into a specified register in the state descriptor of the secure virtual machine, where the state descriptor is stored in a secure portion of the memory that cannot be accessed by the hypervisor.

22. The computer-implemented method according to claim 21, further comprising: Based on determining that the response generated by the hypervisor is invalid, the security interface control intercepts an error condition to the hypervisor.

23. A computer system, comprising: Memory; Security interface control; And A processing unit coupled to the memory and the security interface control, the processing unit being configured to execute a hypervisor that hosts a plurality of virtual machines, the hypervisor being prohibited from directly accessing any data of the secure virtual machine, and wherein the hypervisor is configured to execute a method for interpreting one or more guest instructions from the virtual machines, the method comprising: The hypervisor executes guest instructions from the secure virtual machine, the hypervisor being prohibited from directly accessing any data of the secure virtual machine; The hypervisor stores a response to the guest instructions in a predetermined buffer; and The security interface control updates the state descriptor with the response by copying the response into a specified register in the state descriptor of the secure virtual machine, where the state descriptor is stored in a secure portion of the memory that cannot be accessed by the hypervisor.

24. The system according to claim 23, wherein, The method further comprises: Based on determining that the response generated by the hypervisor is invalid, the security interface control intercepts an error condition to the hypervisor.

25. The system according to claim 23 or 24, wherein, The method further comprises: The security interface control resets a first flag associated with the secure virtual machine, the reset indicating that the secure virtual machine can be dispatched to continue execution of the instruction stream.

Images