Security virtual machine allocation

Abstract

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

Description

Background Art

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

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

[0003] Customers are often concerned about the security of data in virtual machines. Cloud operators may not be trusted, and customers may want to deploy their work without the risk of being compromised by malicious or imperfect code (such as hypervisors) and / or system administrators with malicious intent to operate the data center. Customers may expect security between their code and data and the cloud computing provider, as well as security between their code and data and other VMs running at the provider's location, as well as security from the provider's administrators, and protection against potential security vulnerabilities in other code running on the machine. For example, customers may request that a cloud provider not access their data in order to reduce or avoid the possibility that a cloud computing provider, such as a United States (US) company, may be forced to hand over confidential or proprietary documents through a subpoena. Summary of the invention

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

[0005] In one or more examples, the second state descriptor is accessible only by the security interface control and not by the hypervisor. In one or more examples, the first state descriptor includes a pointer to the second state descriptor. In one or more examples, the security interface control determines the security mode of the virtual machine based on one or more security interface controls authorized by a mask stored in the second state descriptor. In addition, in one or more examples, the security interface control verifies the correctness of the virtual machine state by comparing the values ​​in the first state descriptor and the second state descriptor.

[0006] According to one or more embodiments of the present invention, the method further includes detecting the occurrence of an exit condition of the virtual machine, and based on the security mode being the first mode, executing, through the security interface control, storing the virtual machine state in a first state descriptor stored in a non-secure portion of the memory. The method further includes storing the virtual machine state in a second state descriptor stored in a secure portion of the memory based on the security mode being the second mode.

[0007] According to one or more embodiments of the present invention, the method also includes storing the virtual machine state in a second state descriptor stored in a secure part of the memory based on the security mode being a third mode, and storing one or more selected parameters from the virtual machine state in a first state descriptor stored in a non-secure part of the memory.

[0008] In one or more examples, the security interface control includes millicode.

[0009] According to one or more embodiments of the present invention, a computer-implemented method includes dispatching a secure virtual machine by a hypervisor executed on a host machine, wherein the hypervisor is blocked from directly accessing any data of the secure virtual machine. The method further includes determining the security mode of the secure virtual machine through a security interface control of the host server based on the occurrence of an exit condition of the secure virtual machine. In addition, based on the security mode being a first mode, the security interface control stores the virtual machine state of the secure virtual machine in a first state descriptor, and the first state descriptor is stored in a non-secure portion of a memory. In addition, based on the security mode being a second mode, the security interface control stores the virtual machine state in a second state descriptor, and the second state descriptor is stored in a secure portion of the memory that cannot be accessed by the hypervisor.

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

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

[0012] Features described herein provide improvements to computer technology, and in particular, provide improvements to computer servers that host virtual machines (VMs) by facilitating computer servers to host secure VMs. In the case of secure VMs (where the hypervisor is no longer trusted with control of VM data), dispatching the secure VM through the same hypervisor interface as in existing computer servers remains a preferred (or in some cases required) option for compatibility with existing hypervisors to continue operating. Thus, one or more embodiments of the present invention facilitate that the hypervisor code does not have to be changed so that the same code (of the existing hypervisor) can be used to dispatch typical non-secure VMs as well as secure VMs that disable hypervisor data access in the host computer server.

[0013] 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 are considered to be part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A cloud computing environment according to one or more embodiments of the present invention is shown;

[0016] Figure 2 An abstract model layer according to one or more embodiments of the present invention is shown;

[0017] Figure 3 A block diagram of a system according to one or more embodiments of the present invention is shown;

[0018] Figure 4 A block diagram illustrating a hosting system according to one or more embodiments of the present invention;

[0019] Figure 5 A flowchart illustrating an example method for a hypervisor to start a secure virtual machine according to one or more embodiments of the present invention is shown;

[0020] Figure 6 shows an example structure of a state descriptor according to one or more embodiments of the present invention;

[0021] Figure 7 shows an example structure of a status descriptor field according to one or more embodiments of the present invention; and

[0022] Figure 8 A flow chart of a method for facilitating exit of a secure virtual machine according to a selected security mode according to one or more embodiments of the present invention is shown. DETAILED DESCRIPTION

[0023] Various embodiments of the present invention are described herein with reference to the relevant drawings. Without departing from the scope of the present invention, alternative embodiments of the present invention may be designed. In the following description and accompanying drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are described between elements. Unless otherwise indicated, these connections and / or positional relationships may be direct or indirect, and the present invention is not intended to be limited in this respect. Therefore, the coupling of entities may refer to direct or indirect coupling, and the positional relationship between entities may be direct or indirect positional relationship. In addition, various tasks and process steps described herein may be incorporated into a more comprehensive program or process with additional steps or functionality not described in detail herein.

[0024] The following definitions and abbreviations are used to interpret the claims and specification. As used herein, the terms "comprises," "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 apparatus that includes a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

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

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

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

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

[0029] A virtual machine running as a client under the control of a host hypervisor relies on the hypervisor to transparently provide virtualization services to the client. These services may include, but are not limited to, memory management, instruction emulation, and interrupt handling. One or more embodiments of the present invention may be applied to any interface between a security entity and another untrusted entity that traditionally allows the other entity to access secure resources. For example, for interrupt and exception emulation, the hypervisor typically reads and / or writes to the 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 state of the virtual machine is maintained by a hypervisor executed on the underlying host (physical processor or processor group). From the perspective of a user or software resource, a VM appears to be its own independent physical machine. The terms "hypervisor" and "VM monitor (VMM)" used herein refer to a processing environment or platform service that manages and allows multiple VMs to execute using multiple (sometimes different) OSs on the same host. It should be understood that dispatching a VM includes: a VM installation process and a VM activation (or startup) process. In another example, dispatching the VM includes an activation (or startup) process of the VM (eg, in the case where the VM is previously installed or already exists).

[0030] However, to facilitate secure clients, technical challenges exist where a computer server such as a hosting node must provide additional security between the hypervisor and the secure client so that the hypervisor cannot access data from the VM and therefore cannot provide services such as those described above.

[0031] In currently available technical solutions, management programs (e.g. of Or a virtual machine (KVM) based on an open source software kernel) dispatches a new VM virtual CPU (vCPU) on a physical processing unit or host server by issuing an SIE instruction that causes the start interpreted execution (SIE) to enter the millicode to be called. Millicode is trusted firmware that operates as an extension of the processor hardware. The operand of the SIE instruction is a control block, called a state description, which contains the client state. In existing implementations, the state description resides in the hypervisor storage. During SIE entry, the client state (including general registers and control registers, client instruction addresses, and client program status words (PSWs)) is loaded into the hardware by the millicode. This allows the client vCPU to run on the physical processor. When the vCPU runs on the hardware, the client state is maintained in the hardware. At some point, the hardware / millicode must return control to the hypervisor. This is generally referred to as an SIE exit. For example, 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 to the vCPU to run on the physical processor) expires, this processing may be required. During SIE exit, the millicode saves the current guest state in the state description, since the hardware has the resources to support only a single vCPU at any given time, and it must now load the hypervisor state into the hardware. When the vCPU is not dispatched, its state is maintained in the state description. Since the state description is located within the hypervisor storage, in this case the hypervisor has control over the VM's data, and in some cases, this control is needed to interpret the instructions executed on the VM. Existing hypervisors rely on using such an interface to dispatch vCPUs through SIE instructions.

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

[0033] In one or more examples, such functionality may be provided using millicode and / or other hardware modules, and in this specification, the hardware modules and millicode are collectively referred to as "security interface controls." Thus, one or more embodiments of the present invention facilitate a hypervisor to securely and reliably use the same SIE interface to dispatch and un-dispatch secure vCPUs that are currently used to dispatch and un-dispatch non-secure vCPUs.

[0034] Now, the background technology is briefly described below, followed by a description of specific features used by one or more embodiments of the present invention to dispatch secure VMs by a hypervisor. It should be understood in advance that although the present disclosure includes a detailed description of cloud computing, the implementation of the teachings described herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0035] Cloud computing is a service delivery model for convenient, on-demand network access to a shared pool of configurable computing resources. Configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) can be rapidly deployed and released with minimal management cost 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.

[0036] Features are as follows:

[0037] On-demand self-service: Cloud consumers can unilaterally and automatically deploy computing capabilities, such as server time and network storage, on demand without human interaction with the service provider.

[0038] Broad network access: Computing power is available over the network and accessed through standard mechanisms that facilitate use through different types of thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0039] Resource pooling: The computing resources of a provider are grouped into resource pools to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Typically consumers do not control or know the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center), thus being location-independent.

[0040] Rapid elasticity: Computing capacity can be deployed quickly and elastically (sometimes automatically) to scale up quickly, and released quickly to scale down quickly. To consumers, the available computing capacity for deployment often appears unlimited, and any amount of computing capacity can be accessed at any time.

[0041] Measurable services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being used.

[0042] The service model is as follows:

[0043] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on the cloud infrastructure. The applications can be accessed from a variety of 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.

[0044] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired by consumers on the cloud infrastructure, which are created using programming languages ​​and tools supported by the provider. Consumers neither manage nor control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but can control the deployed applications and possibly the configuration of the application hosting environment.

[0045] Infrastructure as a Service (IaaS): The capability provided to consumers is to deploy processing, storage, network, and other basic computing resources, where consumers can deploy and run arbitrary software, which may include operating systems and applications. Consumers neither manage nor control the underlying cloud infrastructure, but have control over the operating system, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

[0046] The deployment model is as follows:

[0047] Private cloud: Cloud infrastructure is run solely for an organization. It can be managed by the organization or a third party and can exist inside or outside of that organization.

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

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

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

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

[0052] Reference now Figure 1 , depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which cloud consumers can communicate using local computing devices, such as personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped in one or more networks (not shown), such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. In this way, cloud consumers can allow the cloud computing environment 50 to provide infrastructure as a service, platform as a service, and / or software as a service without having to maintain resources on local computing devices. It should be understood that Figure 1 The types of computing devices 54A-N shown in are merely illustrative, and computing node 10 and cloud computing environment 50 may communicate with any type of computing device (eg, using a web browser) over any type of network and / or network-addressable connection.

[0053] Reference now Figure 2 , showing the cloud computing environment 50 ( Figure 6 ) provides a set of functional abstraction layers. It should be understood in advance Figure 2 The components, layers and functions shown in are merely illustrative, and embodiments of the present invention are not limited thereto. As shown in the figure, the following layers and corresponding functions are provided:

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

[0055] Virtualization layer 70 provides an abstraction layer from which examples of the following virtual entities may 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 .

[0056] In one example, the management layer 80 may provide the functions described below. The resource provisioning function 81 provides dynamic acquisition of computing resources and other resources for performing tasks within the cloud computing environment. The metering and pricing function 82 tracks the cost of resource usage within the cloud computing environment and provides bills or invoices for consuming these resources. In one example, these resources may include application software licenses. The security function provides identity authentication for cloud consumers and tasks, as well as 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 allocation and management of cloud computing resources to meet the required service levels. The service level agreement (SLA) planning and fulfillment function 85 provides pre-scheduling and provisioning for future demand for cloud computing resources predicted according to the SLA.

[0057] The workload layer 90 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom instructional provision 93; data analytics processing 94; transaction processing 95; and source code versioning 96. It will be appreciated that these are just some examples, and in other embodiments, these layers may include different services.

[0058] Figure 3 An example hosting node 10 according to 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. In addition, the client devices 20A-20C can communicate directly with the hosting node 10, which can be a data center or 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 or millicode layer 13, which includes a security interface control 11. The security interface control 11 includes one or more hardware modules and millicode, which facilitates the hypervisor 12 to provide one or more services to the virtual machine 15. In the prior art solution, 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 VM 15 through the security interface control 11. In order to facilitate a secure 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 VMs 15.

[0059] For example, the hosting node 10 may facilitate the client device 20A to deploy one or more of the virtual machines 15A-15N. The virtual machines 15A-15N may be deployed in response to respective requests from different client devices 20A-20C. For example, 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 (not running as a virtual machine). The examples described herein concretize the resource provisioning in the hosting node 10 as part of a 'virtual machine', however, the described technical solutions may be applied to provisioning resources as part of a physical server.

[0060] In one example, 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 hosting node 10 may operate as a private cloud for the entity. In this case, hosting node 10 individually hosts virtual machines 15A-15N deployed by client devices 20A-20C belonging to the entity. In another example, client devices 20A-20C may belong to different entities. For example, a first entity may own client device 20A, while a second entity may own client device 20B. In this case, hosting node 10 may operate as a public cloud that hosts virtual machines from different entities. For example, virtual machines 15A-15N may be deployed in a shielded manner in which virtual machine 15A does not facilitate access to virtual machine 15B. For example, hosting node 10 may use IBM z Processor Resource / System Manager (PR / SM) Logical Partition (LPAR) features are used to cover 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 in different logical partitions for different entities on the same physical hosting node 10.

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

[0062] Figure 4 Components of an example hosting node according to one or more embodiments of the present invention are shown. 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 including hardware (e.g., 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 may include, for example, a battery sensor, a position sensor (altimeter 40, accelerometer 42, GPS 44), an indicator / identification light, etc. Input devices such as a traditional keyboard 150 and a mouse 155 may be coupled to the I / O controller 135. The I / O controller 135 may be, for example, one or more buses or other wired or wireless connections as known in the art. The I / O controller 135 may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications, which are omitted for simplicity.

[0063] I / O devices 140, 145 may also include devices that communicate with both input and output ends, 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, etc.

[0064] Processor 105 is a hardware device for executing hardware instructions or software, particularly those stored in memory 110. Processor 105 may be a custom or commercially available processor, a central processing unit (CPU), an auxiliary processor in a plurality of processors associated with hosting node 10, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macroprocessor, or other means for executing instructions. Processor 105 includes 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 data extraction and storage, and a translation lookaside buffer (TLB) for accelerating virtual-to-physical address translation of both executable instructions and data. Cache 170 may be organized into a hierarchy of more cache levels (L1, L2, etc.).

[0065] 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 disk read-only memory (CD-ROM), magnetic disk, floppy disk, magnetic cassette, cassette, 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 in which various components are remote from each other but can be accessed by the processor 105.

[0066] The instructions in memory 110 may include one or more separate programs, each of which includes an ordered list of executable instructions for implementing logical functions. Figure 2In the example of , the instructions in the memory 110 include an appropriate operating system (OS) for executing the hypervisor 12. The operating system can 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 a z system, the manufacturer of the hosting node 10 can provide the hypervisor 12. In the case where the system has a structure different from that of the z system, where the hypervisor 12 is not provided by the hardware manufacturer, the cloud computing provided can use a hypervisor 12 such as from VMWARE or other hypervisor provider. In the example, the administrator of the physical hosting node 10 cannot modify the hypervisor 12 unless necessary in order to apply the services provided by the manufacturer. For example, the hypervisor 12 can be provided as part of the "licensed internal code (LIC)" and / or microcode for the hosting node 10.

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

[0068] The hosting node 10 may also include a display controller 125 coupled to a user interface or 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 hosting node 10 may also include a network interface 160 for coupling to a network 165. The network 165 may be an IP-based network for communicating between the host node 10 and an external server, client, etc. via a broadband connection. In one embodiment, the network 165 may be a satellite network. The network 165 sends and receives data between the hosting 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). 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 system, and may include devices for receiving and sending signals.

[0069] 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 hosting node 10, for example, the client device 20A may request the virtual machine 15A to 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 the virtual machine 15A to have access to a specific hardware component (e.g., an electronic circuit identified by a corresponding unique identifier). For example, the client device 20A may request the virtual machine 15A to 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 conjunction with a version identifier. Alternatively or additionally, the client device 20A may request that the virtual machine 15A have access to a particular software component (e.g., an operating system, an application, a basic input / output system (BIOS), a boot image, or any other software component). The requested software component may include embedded programs in firmware and hardware components of the hosting node 10. The client device 20A may identify the requested software component using a corresponding unique identifier provided by the developer / manufacturer of the corresponding software component. In one example, the identifier may be used in conjunction with a version identifier of the software component.

[0070] As previously described, for the virtual machine 15A that is to become a secure VM, all non-secure clients and hypervisors 12 are prohibited from accessing the memory 110, storage device 120, one or more parts of 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 client page, the associated host absolute address can only be accessed through a single hypervisor (host) DAT mapping. That is, there is a single host virtual address mapped to any given host absolute address assigned to the secure VM 15A. In addition, the hypervisor DAT mapping (host virtual to host absolute) associated with any given secure client page does not change when it is paged in. In addition, the host absolute page associated with any secure client page is only mapped for a single secure client. In addition, there is no sharing of memory / registers between virtual machines 15, especially in the case of secure VM 15A. In addition, in one or more examples, the hypervisor 12 allocates the secure portion of the storage device 120 to the secure interface control 11. This secure portion of the storage device 120 can only be accessed by the secure interface control 11 after being allocated. After the content of the secure portion is assigned to the security interface control 11 , neither the virtual machine 15 nor the hypervisor 12 can access the content of the secure portion.

[0071] Any attempted violation of these rules is prohibited by the security interface control 11 and the managed node 10, and an alarm may be raised. The alarm may be raised by sending a notification to one or more personnel, blocking the operation of the managed node 10, blocking requests from one or more client devices 20, blocking the operation of the secure VM 15 (and any other secure VM), etc.

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

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

[0074] Figure 6 Depicted is an example structure of a SD according to one or more embodiments of the present invention.In one or more examples, the same SD format is used for both secure VMs and non-secure VMs.

[0075] According to one or more embodiments of the invention, the state descriptor (SD) 600 includes a mode control field 602 for indicating whether the assigned VM is secure or non-secure. In one or more examples, the mode control field 602 may be a bit.

[0076] In addition, if the mode control field 602 indicates that the SD 600 is for a secure VM, the unique identification indicator 604 provides a secure customer domain ID for the specific secure VM 15A being assigned. For non-secure VMs, the unique identification indicator 604 is not used and may include a default value, such as 0 (or any other value indicating that the field is not used).

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

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

[0079] Figure 7 An example structure of the SD field according to one or more embodiments of the present invention is described. In this context, the term "status descriptor" includes not only the status description itself, but also the satellite blocks, whose pointers reside in the status description, used as extensions. Figure 7 As shown, the SD field 606 may include VM general registers (GR) 402, access registers (AR) 404, control registers (CR) 406, VM timers 408 (including clock comparators and CPU timers), VM prefix registers 410, logical partition numbers (LPNs) 432, virtual CPU numbers (VCNs) 412, thread validity masks (TVMs) 430, program status words (PSWs), and instruction addresses (IAs) 414. In addition, it may include control information, such as an intercept control (IC) bit 420, to indicate whether certain instructions (e.g., loader status word (LPSW) and invalid page table entry (IPTE)) require interception of the host. The SD field 606 shown is exemplary and may be different in one or more embodiments of the present invention, such as including various other fields for other VM states.

[0080] Return to reference Figure 5, the hypervisor 12 issues a SIE instruction with the SD 600 as an operand, and the execution of the instruction is performed by the secure interface control 11. The SIE (Start Interpretation Execution) instruction is used to start the VM 15 and allocate the processor 105 and other computing resources to the VM 15. At 510, the secure interface control 11 determines whether the VM to be dispatched is secure based on the mode control field 602 in the SD 600. If a non-secure VM is to be dispatched, as is currently done, at 515, the SD field 606 from the SD 600 is used to dispatch the non-secure VM 15B. The SIE instruction puts the processor 105 into an emulation state defined in the SD.

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

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

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

[0084] For example, consider three debug security operation modes for the secure execution environment of secure VM 15A: transparent, semi-transparent, and fully transparent modes. The transparent debug mode is used to allow the hypervisor 12 to view only the registers of VM 15, without viewing the secure memory associated with VM 15. In this mode, the parent, non-secure SD 600 saves the registers of VM 15, and the secure SD 650 that will be used for verification (520) in other modes is not used. In the semi-transparent mode, although the registers of VM 15 are saved in the secure SD 650, when the instruction of VM 15 is intercepted or interrupted, the secure interface control 11 determines which (some) registers are exposed to the hypervisor 12 by copying the registers to the non-secure parent SD 600. In the non-transparent mode, the client registers are not exposed to the hypervisor 12 at all, and are only maintained in the secure SD 650.

[0085] At 535, the method ( Figure 5 ) determines the debug security mode selected based on the security interface control for control. The hardware controls that provide these operating modes are masked by the debug mask field stored in the security SD 650, that is, the security SD 650 has information indicating which of the three debug modes is allowed. The security interface control 11 is able to change the debug mask in the security SD 650 at runtime when necessary. In the case where the fully transparent mode is selected, at 540, the SD field 606 from the non-secure SD 600 is used to dispatch the VM 15. In this case, the hypervisor is allowed to access the complete register state of the dispatched VM 15. In the case where the semi-transparent mode or the non-transparent mode is selected, the SD field 606 from the security SD 650 is used to dispatch the security VM 15A at 545 and 550, respectively. Then, the dispatched VM is executed 560 until the exit condition is reached 565. The exit condition may include instruction or interrupt interpretation, user request to exit the VM, etc.

[0086] Figure 8 A flow chart of a method for facilitating the exit of a secure VM according to a selected debug security mode according to one or more embodiments of the present invention is shown. At 801, the method is initiated after an exit condition of a VM occurs. At 805, the security interface control 11 checks the debug security mode selected for the VM when the VM is dispatched.

[0087] In the case where the fully transparent mode is selected 805, the VM state is stored in the SD field 606 in the non-secure state description 600. That is, at 810, the VM is exited similar to a non-secure VM as done in existing solutions. By setting one or more parameters of the computing resources 850, the computing resources associated with the VM 15 are configured to be in hypervisor mode. The SD field 606 from the SD 600 resides in non-secure memory and is accessible by the hypervisor 12.

[0088] In the case where the non-transparent debug secure mode is selected 805, the VM 15 is exited as a secure VM, and even after the VM exits, the hypervisor cannot access any data / memory or other parameters of the VM state. Therefore, at 820, the secure interface control 11 saves the VM state to the SD field 606 in the secure SD 650, which resides in the secure portion of the memory 110 and cannot be accessed by the hypervisor 12. In addition, at 822, the secure interface control 11 reconfigures the computing resources associated with the VM 15 to operate in a non-secure mode.

[0089] In the case where the semi-transparent debug security mode is selected, at 830, the security interface control 11 determines whether hypervisor assistance has been requested for completing tasks associated with the VM 15. For example, such an assistance request may be made when one or more values ​​associated with the VM 15 are to be accessed via the hypervisor 12 for debugging or any other such task. If hypervisor assistance is requested, the security interface control 11 determines at 832 what data associated with the VM 15 will be accessible to the hypervisor when the VM 15 exits. In one or more examples, the assistance request includes an identification of which register(s) from the VM 15 will be accessible by the hypervisor 12. Alternatively, or in addition, the assistance request may include an identification of any other parameter from the VM state that will be accessible to the hypervisor 12 when the VM 15 exits.

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

[0091] If no hypervisor assistance request is made (830), then at 820, the security interface control 11 saves the VM state to the SD field 606 in the secure SD 650 that is not accessible to the hypervisor 12. In addition, at 822, the security interface control 11 reconfigures the computing resources associated with the VM 15 to operate in a non-secure mode.

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

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

[0094] According to one or more embodiments of the present invention, a computer server can host a secure VM that prohibits a hypervisor from accessing memory, registers, and other data associated with a secure VM without having to change the hypervisor and / or secure VM code / architecture to dispatch the secure VM. In contrast, according to one or more embodiments of the present invention, a security interface control including millicode uses an improved structure of state descriptors and secure portions of storage devices / memory to facilitate protecting data. In addition, the security interface control stores data from the VM state based on a debug security mode, so that if one or more parameters are to be made accessible to the hypervisor, the security interface control (millicode) can do so.

[0095] One or more embodiments of the present invention are rooted in computer technology, and in particular virtual machine-hosted computer servers. Furthermore, one or more embodiments of the present invention facilitate improvements to the operation of computing technology itself, and in particular virtual machine-hosted computer servers, by facilitating computer servers that host VMs to host secure VMs, wherein even the hypervisor is prohibited from accessing memory, registers, and other such data associated with the secure VM. Furthermore, one or more embodiments of the present invention provide an important step toward improvements to VMs that host compute servers through the use of secure interface controls that include millicode to facilitate separation of the secure VM and the hypervisor, and thereby maintain the security of the VMs hosted by the compute server. The secure interface controls provide lightweight intermediate operations to facilitate security without adding substantial overhead to protecting the VM state during initialization / exit of the VM as described herein.

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

[0097] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may 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 computer-readable storage media 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 punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage medium used here should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse transmitted by a fiber optic cable), or an electrical signal transmitted by a wire.

[0098] 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 transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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 to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0099] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and process programming languages ​​such as "C" programming language or similar programming languages. The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can 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, can be connected to an external computer (for example, using an Internet service provider to connect through the Internet). In some embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be personalized by using the state information of the computer-readable program instructions to customize the electronic circuit, and the electronic circuit executes the computer-readable program instructions to perform various aspects of the present invention.

[0100] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It will be understood that each box in the flowchart illustration and / or block diagram and the combination of boxes in the flowchart illustration and / or block diagram can be implemented by computer-readable program instructions.

[0101] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in the flowchart and / or a block diagram block or multiple block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can cause a computer, a programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium with instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in the flowchart and / or a block diagram block or multiple block diagram blocks.

[0102] 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 executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in the flowchart and / or a block diagram block or multiple block diagram blocks.

[0103] The flow charts and block diagrams in the accompanying drawings illustrate the system, method and computer program product according to various embodiments of the present invention. The architecture, function and operation of the possible implementation methods. In this regard, each box in the flow chart or block diagram can represent a part of a module, a program segment or an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in the box may not occur in the order shown in the figure. For example, the two boxes shown in succession can actually be executed substantially in parallel, or these boxes can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart illustration and the combination of boxes in the block diagram and / or flow chart illustration can be implemented by a dedicated hardware-based system that performs a specific function or action, or performs a combination of dedicated hardware and computer instructions.

[0104] The description of various embodiments of the present invention has been presented for the purpose 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 are selected to best explain the principles of the embodiments, practical applications, or technical improvements over existing technologies on the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method comprising: Receiving, by a hypervisor executing on a host server, a request to dispatch a virtual machine; Based on determining that the virtual machine is a secure virtual machine, preventing the hypervisor from directly accessing any data of the secure virtual machine; as well as The security interface control performed by the host server: Determining a security mode of the virtual machine; Based on the security mode being a first mode, loading a virtual machine state from a first state descriptor for the virtual machine, the first state descriptor being stored in a non-secure portion of a memory; as well as Based on the security mode being a second mode, loading the virtual machine state from a second state descriptor for the virtual machine, the second state descriptor being stored in the secure portion of the memory, wherein the first state descriptor includes a pointer to the second state descriptor.

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

3. The computer-implemented method of claim 1 or 2, wherein: The security interface control determines the security mode of the virtual machine based on one or more security interface controls authorized with a mask stored in the second state descriptor.

4. The computer-implemented method of claim 1 or 2, wherein: The security interface control verifies the correctness of the virtual machine state by comparing the values ​​in the first state descriptor and the second state descriptor.

5. The computer-implemented method of claim 1 or 2, further comprising: Detecting the occurrence of an exit condition of the virtual machine; as well as Executed by the security interface control: Based on the secure mode being the first mode, storing the virtual machine state in the first state descriptor stored in the non-secure portion of the memory; as well as Based on the secure mode being the second mode, storing the virtual machine state in the second state descriptor stored in the secure portion of the memory.

6. The computer-implemented method of claim 5, further comprising: Based on the security mode being a third mode, the virtual machine state is stored in the second state descriptor stored in the secure portion of the memory, and one or more selected parameters from the virtual machine state are stored in the first state descriptor stored in the non-secure portion of the memory.

7. The computer-implemented method of claim 1 or 2, wherein: The secure interface control includes millicode.

8. A computer-implemented system comprising: Memory; Security interface controls; as well as A processing unit coupled to the memory and the security interface control, the processing unit being configured to execute a hypervisor for hosting 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 managing startup and exit of the virtual machine, the method comprising: Receiving, by the hypervisor, a request to dispatch a virtual machine; Based on determining that the virtual machine is a secure virtual machine, preventing the hypervisor from directly accessing any data of the secure virtual machine; and Executed by the security interface control: Determining a security mode of the virtual machine; Based on the security mode being a first mode, loading a virtual machine state from a first state descriptor for the virtual machine, the first state descriptor being stored in a non-secure portion of a memory; and Based on the security mode being a second mode, loading the virtual machine state from a second state descriptor for the virtual machine, the second state descriptor being stored in the secure portion of the memory, wherein the first state descriptor includes a pointer to the second state descriptor.

9. The system according to claim 8, wherein: The second state descriptor is accessible only by the secure interface control and is not accessible by the hypervisor.

10. The system according to claim 8 or 9, wherein: The security interface control determines the security mode of the virtual machine based on one or more security interface controls authorized with a mask stored in the second state descriptor.

11. The system according to claim 8 or 9, wherein: The security interface control verifies the virtual machine state by comparing values ​​in the first state descriptor and the second state descriptor.

12. The system according to claim 8 or 9, wherein: The method further comprises: detecting occurrence of an exit condition of the virtual machine; and Executed by the security interface control: Based on the secure mode being the first mode, storing the virtual machine state in the first state descriptor stored in the non-secure portion of the memory; and Based on the secure mode being the second mode, storing the virtual machine state in the second state descriptor stored in the secure portion of the memory.

13. The system according to claim 12, wherein: The method further comprises: Based on the security mode being a third mode, the virtual machine state is stored in the second state descriptor stored in the secure portion of the memory, and one or more selected parameters from the virtual machine state are stored in the first state descriptor stored in the non-secure portion of the memory.

14. A computer program product comprising a computer-readable storage medium, the computer-readable storage medium comprising computer-executable instructions, the computer-executable instructions, when executed by a processing unit, causing the processing unit to perform a method comprising: Receiving, by a hypervisor executing on a host server, a request to dispatch a virtual machine; Based on determining that the virtual machine is a secure virtual machine, preventing the hypervisor from directly accessing any data of the secure virtual machine; as well as The security interface control performed by the host server: Determining a security mode of the virtual machine; Based on the security mode being a first mode, loading a virtual machine state from a first state descriptor for the virtual machine, the first state descriptor being stored in a non-secure portion of a memory; as well as Based on the security mode being a second mode, loading the virtual machine state from a second state descriptor for the virtual machine, the second state descriptor being stored in the secure portion of the memory, wherein the first state descriptor includes a pointer to the second state descriptor.

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

16. A computer program product according to claim 14 or 15, wherein: The method further comprises: detecting occurrence of an exit condition of the virtual machine; and Executed by the security interface control: Based on the secure mode being the first mode, storing the virtual machine state in the first state descriptor stored in the non-secure portion of the memory; and Based on the secure mode being the second mode, storing the virtual machine state in the second state descriptor stored in the secure portion of the memory.

17. The computer program product of claim 16, wherein: The method further comprises: Based on the security mode being a third mode, the virtual machine state is stored in the second state descriptor stored in the secure portion of the memory, and one or more selected parameters from the virtual machine state are stored in the first state descriptor stored in the non-secure portion of the memory.

18. A computer-implemented method comprising: dispatching, by a hypervisor executing on a host machine, a secure virtual machine, wherein the hypervisor is prevented from directly accessing any data of the secure virtual machine; and Based on the occurrence of the exit condition of the secure virtual machine, the secure interface control of the host server executes: Determining a security mode of the secure virtual machine; Based on the security mode being the first mode, storing the virtual machine state of the secure virtual machine in a first state descriptor, the first state descriptor being stored in a non-secure portion of a memory; and Based on the security mode being the second mode, the virtual machine state is stored in a second state descriptor, the second state descriptor being stored in a secure portion of the memory that is not accessible by the hypervisor, wherein the first state descriptor includes a pointer to the second state descriptor.

19. The computer-implemented method of claim 18, further comprising: Based on the security mode being a third mode, the virtual machine state is stored in the second state descriptor stored in the secure portion of the memory, and one or more selected parameters from the virtual machine state are stored in the first state descriptor stored in the non-secure portion of the memory.

20. A computer-implemented system comprising: Memory; Security interface controls; as well as A processing unit coupled to the memory and the security interface control, the processing unit being configured to execute a hypervisor for hosting 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 managing startup and exit of the virtual machine, the method comprising: A secure virtual machine is assigned by the hypervisor, the hypervisor being prevented from directly accessing any data of the secure virtual machine; Detecting the occurrence of an exit condition of the secure virtual machine; and Performed by the security interface control: Determining a security mode of the secure virtual machine; Based on the security mode being the first mode, storing the virtual machine state of the secure virtual machine in a first state descriptor, the first state descriptor being stored in a non-secure portion of a memory; and Based on the security mode being the second mode, the virtual machine state is stored in a second state descriptor, the second state descriptor being stored in a secure portion of the memory that is not accessible by the hypervisor, wherein the first state descriptor includes a pointer to the second state descriptor.

21. The system of claim 20, wherein: The method further comprises: Based on the security mode being a third mode, the virtual machine state is stored in the second state descriptor stored in the secure portion of the memory, and one or more selected parameters from the virtual machine state are stored in the first state descriptor stored in the non-secure portion of the memory.

22. The system according to claim 20 or 21, wherein: The security interface control determines the security mode of the secure virtual machine based on one or more security interface controls authorized with the mask stored in the second state descriptor.

Images