Patent Description:
Cloud computing and storage provides users with capabilities to store and process their data in third-party data centers. Cloud computing facilitates the ability to provision a virtual machine (VM) for a customer quickly and easily, without requiring the customer to purchase hardware or provide floor space for a physical server. The customer may expand or contract the VM according to changing preferences or requirements of the customer. Typically, a cloud computing provider provisions the VM, which is physically resident on a server at the provider's data center. Customers are often concerned about the security of data in the VM, particularly since computing providers often store more than one customer's data on the same server. The customer may desire security between its code/data and the cloud computing provider, as well as between its code/data and that of other VMs running at the provider's site. In addition, the customer may desire security from the provider's administrators, as well as against potential security breaches in other code running on the machine.

To handle such sensitive situations, cloud service providers may implement security controls to ensure proper data isolation and logical storage segregation. The extensive use of virtualization in implementing cloud infrastructure results in unique security concerns for customers of cloud services as virtualization alters the relationship between an operating system (OS) and the underlying hardware, be it computing, storage, or even networking. This introduces virtualization as an additional layer that itself must be properly configured, managed and secured. The non-patent publication "<NPL>et al. represents relevant prior art.

According to one or more embodiments of the present invention, a non-limiting example method includes receiving, by a hypervisor that is executing on a host server, a request to dispatch a virtual machine (VM) on the host server. The VM is dispatched on the host server by the hypervisor. The VM includes a reboot instruction. The reboot instruction is triggered by the hypervisor to restart the VM in a secure mode. Technical effects and benefits of the one or more embodiments can include the ability to start a secure VM using a reboot instruction being executed by a non-secure VM.

In accordance with additional or alternative embodiments of the present invention, the reboot instruction utilizes an initial program load (IPL) mechanism. Technical effects and benefits can include the ability to use a standard IPL mechanism to start a secure VM.

In accordance with additional or alternative embodiments of the present invention, the dispatching includes loading an encrypted image of the VM into a memory of the host server, and loading an unencrypted bootstrap component comprising the reboot instruction into the memory. Technical effects and benefits can include the ability for a hypervisor to start the VM in a non-secure mode without first decrypting an image of the VM.

In accordance with additional or alternative embodiments of the present invention, the dispatching further includes transferring control to the unencrypted bootstrap component. Technical effects and benefits can include the ability for a hypervisor to start the VM in a non-secure mode without first decrypting an image of the VM and then transferring control to a bootstrap component for restarting the VM in a secure mode.

In accordance with additional or alternative embodiments of the present invention, the VM includes encrypted components subsequent to the dispatching. Technical effects and benefits can include the ability for a hypervisor to start the VM in a non-secure mode without first decrypting an image of the VM.

In accordance with additional or alternative embodiments of the present invention, the restart includes decrypting the encrypted components of the VM. Technical effects and benefits can include decrypting an encrypted VM image as part of a restart process.

In accordance with additional or alternative embodiments of the present invention, the VM dispatched by the hypervisor is in a non-secure mode and data of the VM is accessible by the hypervisor. Technical effects and benefits can include the ability for a hypervisor to start the VM in a non-secure mode without first decrypting an image of the VM.

In accordance with additional or alternative embodiments of the present invention, based on a determination that the VM is in the secure mode, preventing the hypervisor from accessing any data of the VM. Technical effects and benefits can include the ability to provide a secure VM environment.

In accordance with additional or alternative embodiments of the present invention, the VM on the host server includes an encrypted image of the VM. In addition, triggering the reboot instruction includes the hypervisor calling a secure interface control to perform the restart in a secure mode, the hypervisor specifying a location of the encrypted image of the VM on the host server and decryption information.

In accordance with additional or alternative embodiments of the present invention, performing the restart includes decrypting, by the secure interface control, the VM based on the decryption information. It also includes restarting the VM based on the decrypted VM, wherein the subsequent to the restarting, the hypervisor is prevented from accessing any data of the VM.

Other embodiments of the present invention implement the features of the above-described methods in computer systems and in computer program products.

Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the invention. For a better understanding of the invention with the advantages and the features, refer to the description and to the drawings.

The diagrams depicted herein are illustrative. There can be many variations to the diagram or the operations described therein without departing from the scope of the invention as defined by the claims. For instance, the actions can be performed in a differing order or actions can be added, deleted or modified. Also, the term "coupled" and variations thereof describes having a communications path between two elements and does not imply a direct connection between the elements with no intervening elements/connections between them. All of these variations are considered a part of the specification.

In accordance with one or more embodiments of the present invention, a new initial program load (IPL) mechanism is provided to allow a guest, or virtual machine (VM), executing on a host server to request a transfer into a secure mode. When in the secure mode, the hypervisor does not have access to the data of the VM. In accordance with one or more embodiments of the present invention, when a VM is executing in a secure mode, a secure interface control implemented in hardware and/or firmware is used to provide isolation between the secure guest and other guests executing on the host server.

In accordance with one or more embodiments of the present invention an encrypted image of a VM is loaded into a VM memory of a host server along with an unencrypted bootstrap component. The bootstrap component has access to information about all memory pages of the encrypted image of the VM as well as a meta-data structure for use in decrypting the image and restarting the VM in a secure mode (i.e., as a secure guest). In accordance with one or more embodiments of the present invention the meta-data structure also includes a list of contiguous regions of the operating system image which can be used. As known in the art, instead of listing all memory pages of an operating system individually, a list of regions that each includes a starting page and number of pages can save space and speed-up processing. For example, if a hypothetical operating system image resides in pages <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, this could be specified as (<NUM>, <NUM>) and (<NUM>,<NUM>).

In accordance with one or more embodiments of the present invention, the bootstrap component triggers a re-boot, or restart, operation by preparing an IPL information block in a new format; setting the IPL information block using, for example a "Diagnose <NUM> Subcode <NUM>"; and performing the IPL using, for example, a "Diagnose <NUM> Subcode <NUM>" or a new code. The IPL information block can include: a secure execution (SE) header with an image key and integrity values; a list of memory regions that need to be decrypted; and initialization vectors (IVs), that have been used for the encryption of all pages of the image. In a conventional environment, the IPL information block contains the identification of the boot source, which can be the disk device address, a denomination like CDROM, and so on. For the secure environment implemented by one or more embodiments of the present invention, the boot source identifying information includes encryption keys and memory regions that need to be decrypted. Depending on the encryption method used, one or more embodiments of the present invention implement IVs to add randomness to the encryption. An unique IV can be provided for each of the memory regions. This type of cryptographic method that utilizes IVs can be used to improve the quality of encryption. For example, if two identical memory pages are encrypted with the same secret key but with a different IVs, the encrypted content will be different, which makes it impossible for an adversary to know that content is identical.

"Diagnose" is an example of an instruction that allows a guest operating system to interact with a hypervisor. The Diagnose instruction is used by IBM z Systems®, and Diagnose <NUM> is specifically used for program-directed IPL (allows the guest to request a reboot) operation. Subcode <NUM> is used to set the IPL parameters (e.g. boot device to use) and subcode <NUM> is used to trigger the reboot from the boot device previously specified by subcode <NUM>. The mechanism to request a reboot from within an operating system is architecture dependent. On some x86 machines, it is possible to change the boot device using commercially available software tools.

In accordance with one or more embodiments of the present invention, the hypervisor uses the information from the IPL information block, including the SE header to call the secure interface control (also referred to herein as an "ultravisor") to create a secure guest configuration and perform the unpacking, or decrypting of the encrypted VM image. If the unpacking succeeds, then the unpacked VM gains control, executing in a secure mode. If the unpacking fails, then the VM enters a disabled wait state in non-secure mode.

A VM, running as a guest under the control of a host hypervisor, relies on that hypervisor to transparently provide virtualization services for that guest. These services can apply to any interface between a secure entity and another untrusted entity that traditionally allows access to the secure resources by this other entity. These services can include, but are not limited to memory management, instruction emulation, and interruption processing. For example, for interrupt and exception injection the hypervisor typically reads and/or writes into a prefix area (low core) of the guest. The term "virtual machine" or "VM" as used herein refers to a logical representation of a physical machine (computing device, processor, etc.) and its processing environment (operating system (OS), software resources, etc.) The VM is maintained as software that executes on an underlying host machine (physical processor or set of processors). 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 permits multiple VM's to execute using multiple (and sometimes different) OS's on a same host machine. It should be appreciated that deploying a VM includes an installation process of the VM and an activation (or starting) process of the VM. In another example, deploying a VM includes an activation (or starting) process of the VM (e.g., in case the VM is previously installed or already exists).

However, for facilitating secure guests, a technical challenge exists where additional security is required between the hypervisor and the secure guests, such that the hypervisor cannot access data from the VM, and hence, cannot provide services such as those described above.

In presently available technical solutions, the hypervisor (e.g., z/VM® by IBM® or open source software Kernel Based Virtual machine (KVM)) starts a new VM on a physical processing unit, or host server, by issuing a Start-Interpretive-Execution (SIE) instruction. Part of a state of the VM and its characteristics are saved in control blocks (as a state description or "SD") pointed to by an operand of the SIE instruction (typically the second operand). The hypervisor, in such cases, has control of the data for the VM, and in some cases such control is required to interpret instructions being executed on the VM. Existing hypervisors rely on using such an interface through the SIE instruction to start VMs.

The secure execution described herein provides a hardware mechanism to guarantee isolation between secure storage and non-secure storage as well as between secure storage belonging to different secure users. For secure guests, additional security is provided between the "untrusted" hypervisor and the secure guests. In order to do this, many of the functions that the hypervisor typically does on behalf of the guests need to be incorporated into the machine. The secure interface control provides a secure interface between the hypervisor and the secure guests. The secure interface control works in collaboration with the hardware to provide this additional security. The term ultravisor (UV) is used herein to refer to one example of a secure interface control that can be implemented by one or more embodiments of the present invention.

The secure interface control, in one example, is implemented in internal, secure, and trusted hardware and/or firmware. For a secure guest or entity, the secure interface control provides the initialization and maintenance of the secure environment as well as the coordination of the dispatch of these secure entities on the hardware. While the secure guest is actively using data and it is resident in host storage, it is kept "in the clear" in secure storage. Secure storage can be accessed by that single secure guest - this being strictly enforced by the hardware. That is, the secure interface control prevents any non-secure entity (including the hypervisor or other non-secure guests) or different secure guest from accessing that data. In this example, the secure interface control runs as a trusted part of the lowest levels of firmware. The lowest level, or millicode, is really an extension of the hardware and is used to implement the complex instructions and functions defined in z/architecture. Millicode has access to all parts of storage, which in the context of secure execution, includes its own secure UV storage, non-secure hypervisor storage, secure guest storage, and shared storage. This allows it to provide any function needed by the secure guest or by the hypervisor in support of that guest. The secure interface control also has direct access to the hardware which allows the hardware to efficiently provide security checks under the control of conditions established by the secure interface control.

One or more embodiments of the present invention provide technological improvements over existing systems that utilize encrypted VM images. Existing systems decrypt the encrypted VM image prior to starting the VM on a host machine. A disadvantage of this approach is that specialized computer instructions are required in the hypervisor to determine whether a VM image is encrypted and to perform the decryption prior to dispatching, or starting, the VM on the host machine. One or more embodiments of the present invention do not require updates to the hypervisor dispatch code or require that the hypervisor be aware that a VM image is encrypted prior to the VM being started on a host machine. In addition, the hypervisor can be utilized to start a secure VM even though once the secure VM is started, the hypervisor does not have access to any data of the secure VM.

One or more embodiments of the present invention provide technological improvements over existing systems by providing a secure environment for executing a VM on a host server that hosts a plurality of VMs. Practical applications of one or more embodiments of the present invention include the ability to prevent unauthorized access (intentional or unintentional) to any data of a secure guest executing on a host machine.

Turning now to <FIG>, a schematic diagram of a system <NUM> for starting a secure guest using an IPL mechanism is generally shown in accordance with one or more embodiments of the present invention. The system <NUM> shown in <FIG> includes a guest address space <NUM> of a host server, a host disk including a basic input/output system (BIOS) <NUM>, or loader, and a guest disk that stores operating system components of the secure guest. The terms "guest" and "virtual machine" or "VM" are used interchangeably herein. The operating system components of the secure guest shown in <FIG> include an unencrypted bootstrap component <NUM> and an encrypted image of the guest <NUM>. In accordance with one or more embodiments of the present invention, a hypervisor that is executing on the host server is instructed to load the guest into the guest address space <NUM>. The hypervisor receives information about where the image of the guest is located, in this case on the guest disk, and initiates the BIOS <NUM> to load the operating system components into the guest address space <NUM>.

When the BIOS <NUM> is done loading the operating system components into the guest address space <NUM>, the guest appears to the hypervisor as a non-secure guest. The hypervisor is not aware that the image of the guest is encrypted and not currently operational. The hypervisor transfers control to the bootstrap component <NUM> whose address is specified, which triggers an initial program load (IPL), or restart, of the guest in a secure mode by the ultravisor. In an IBM Z® implementation, the disk with the operating system components contains a hidden bootmap file which describes where the components reside on disk, to which memory locations they must be loaded, and the address of the first instruction to execute after the initial loading has completed (i.e., the starting address of the bootstrap component). One or more embodiments can be implemented by other architectures which may have a fixed memory address that is used to start execution of the operating system.

As shown in <FIG>, the bootstrap component <NUM> includes the bootstrap code executed by the hypervisor to trigger the transition into a secure mode as well as a SE header which includes metadata used by the ultravisor to decrypt the encrypted image of the guest <NUM>.

Turning now to <FIG>, a flow diagram of a process <NUM> for starting a secure guest using an initial program load (IPL) mechanism is generally shown in accordance with one or more embodiments of the present invention. The processing shown in <FIG> can be performed by a combination of a hypervisor and an ultravisor executing on a host machine. The processing shown in <FIG> is performed after operating system components, such the encrypted image of the guest <NUM> and the bootstrap component <NUM> of <FIG>, have been loaded into the memory of a host server, such as guest address space <NUM> of <FIG> and control has been transferred to the bootstrap component.

At block <NUM>, the guest (e.g., the bootstrap code running in the guest) calls the hypervisor to set IPL parameters. The IPL parameters can include, but are not limited to the SE header, a memory region, and initialization vectors (IVs) used for decryption. As used herein, the term "SE header" refers to a data structure containing sensitive information about the operating system, such as the key used to decrypt the operating system image. As this information is sensitive, parts of the SE header must be encrypted, so that only the secure control interface is able to decrypt this data in the SE header. The memory region specifies which memory region(s) in the encrypted image require decryption. In accordance with one or more embodiments of the present invention private/public key pairs are used to perform the encryption and decryption. The VM image can be encrypted using a public key known to the person or entity performing the encryption, and the VM image can be decrypted using a private key known to the ultravisor. One or more embodiments of the present invention may implement any encryption/decryption scheme known in the art, and private/public key pairs are just one example of a scheme that may be implemented. Since the key contained in the SE header is protected, the image encryption key can also be a symmetric key (and used for the decryption as well).

At block <NUM> of <FIG>, the hypervisor determines whether the IPL parameters are valid. The validation can include checking the presence of a SE header, the presence of at least one memory region and ensuring that multiple memory regions don't overlap. At block <NUM>, the hypervisor is performing the validity checks and storing the parameters in some memory location owned by the hypervisor and not accessible to the guest. Therefore, the existence of the parameter is a sufficient indication for their validity.

If it is determined, at block <NUM>, that the IPL parameters are not valid, processing continues at block <NUM> and the guest continues executing in a non-secure mode. If it is determined, at block <NUM>, that the IPL parameters are valid, then processing continues at block <NUM> with the guest calling the hypervisor to perform a reboot. At block <NUM>, the hypervisor verifies that the IPL parameters have been supplied and checked.

If it is determined, at block <NUM> of <FIG>, that the IPL parameters have not been both supplied and checked, then processing continues at block <NUM> and the guest continues executing in a non-secure mode. If it is determined, at block <NUM>, that the IPL parameters have been supplied and checked, then processing continues at block <NUM>. At block <NUM>, the hypervisor calls the ultravisor to create a secure guest configuration, to unpack (e.g., decrypt) the encrypted image, and to start secure execution of the guest. At block <NUM> it is determined whether the image was successfully decrypted and optionally verified. In accordance with one or more embodiments of the present invention the decryption is verified by comparing a checksum or hash computed over the image with a checksum stored in the SE header. If the image was decrypted and verified, then processing continues at block <NUM> with the guest running in a secure mode (i.e., as a secure guest) under control of the ultravisor. If the image was not decrypted and verified, then processing continues at block <NUM> with the guest entering a disabled wait state in the non-secure mode.

Turning now to <FIG>, a schematic diagram of a system <NUM> that includes a secure guest loaded on a host server is generally shown in accordance with one or more embodiments of the present invention. The system <NUM> shown in <FIG> depicts a state of the system <NUM> of <FIG> after the encrypted image is decrypted and the secure system is started on the host machine using a process such as that shown in <FIG>. As shown in <FIG>, an unencrypted version of the image <NUM> is loaded into the guest address space <NUM> and control has been given to the kernel of the guest to start the secure guest.

Turning now to <FIG>, a schematic diagram of an IPL information block <NUM> for starting a secure guest is generally shown in accordance with one or more embodiments of the present invention. The overall layout of the IPL information block shown in block <NUM> is a typical IPL block layout that includes fields for specifying: a length of the block (e.g., in bytes); a version number; a parameter block for load device information such as disk device address, a generic boot device denomination like "CDROM" or a network address; and a parameter block for additional system control parameter (SCP) data that may be used, if the boot method requires parameters not fitting into the first part of the information block. The parameter block for load device information <NUM> is also a typical IPL block layout with the exception of the type field which in accordance with one or more embodiments of the present invention also includes memory (along with disk, network, etc.) as a new type of IPL being performed. This allows the IPL to load data from the memory of the host server which is where the encrypted VM image is located. In addition, the load device specific parameters block includes new types of information used by the hypervisor to perform the decryption: a SE header <NUM> with information used to perform the decryption; and image information <NUM> which can include information that describes the structure of the image in memory.

Turning now to <FIG>, a process flow <NUM> for starting a secure guest is generally shown in accordance with one or more embodiments of the present invention. The processing shown in <FIG> can be performed by a hypervisor executing on a host server. At block <NUM>, a request to dispatch a VM on a host server is received by a hypervisor that is executing on the host server. At block <NUM>, the VM is dispatched on the host server in non-secure mode. When the VM is in non-secure mode, the data of the VM is accessible by the hypervisor. The VM includes a bootstrap component containing a reboot instruction used to restart the VM. In accordance with one or more embodiments of the present invention, the dispatching includes loading an encrypted image of the VM into a memory of the host server and loading an unencrypted bootstrap component that includes the reboot instruction into the memory. The dispatching also includes transferring control to the bootstrap component.

At block <NUM>, in accordance with one or more embodiments of the present invention, a secure reboot is initiated by the bootstrap component. The bootstrap component (<NUM>) sets the IPL information and (<NUM>) requests the reboot. Both (<NUM>) and (<NUM>) are intercepted by the hypervisor which in response to (<NUM>) hands over control to the ultravisor to do the decryption. When the decryption is complete, the ultravisor transfers control to the now secure guest, bypassing the hypervisor. In accordance with one or more embodiments of the present invention, the restarting includes decrypting the encrypted components of the VM. When the VM is in a secure mode the hypervisor is prevented from accessing any data of the VM.

Workloads layer <NUM> provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation <NUM>; software development and lifecycle management <NUM>; virtual classroom education delivery <NUM>; data analytics processing <NUM>; transaction processing <NUM>; and dispatching secure guests <NUM>. It is understood that these are just some examples and that in other embodiments, the layers can include different services.

Turning now to <FIG>, a system <NUM> is depicted in accordance with one or more embodiments of the present invention. The system <NUM> includes an example node <NUM> (e.g., a hosting node) that is in communication with one or more client devices 20A-20C via a network <NUM>. The node <NUM> can be a datacenter or host server, of a cloud-computing provider. The node <NUM> executes a hypervisor <NUM>, which facilitates deploying one or more VMs <NUM> (15A-15N). The node <NUM> further includes a hardware/firmware layer <NUM> that facilitates the hypervisor <NUM> in providing one or more services to the VMs <NUM>. In existing technical solutions, there are communications between hypervisor <NUM> and the hardware/firmware layer <NUM>; the hardware/firmware layer <NUM> and one or more VMs <NUM>; the hypervisor <NUM> and the one or more VMs <NUM>; and the hypervisor <NUM> to VMs <NUM> through the hardware/firmware layer <NUM>. To facilitate a secure VM environment, the hosting node <NUM> according to one or more embodiments of the present invention, does not include any direct communications between the hypervisor <NUM> and the one or more VMs <NUM>.

For example, the node <NUM> can facilitate a client device 20A to deploy one or more of the VMs 15A-15N. The VMs 15A-15N may be deployed in response to respective requests from distinct client devices 20A-20C. For example, the VM 15A may be deployed by the client device 20A, the VM 15B may be deployed by the client device 20B, and the VM 15C may be deployed by the client device 20C. The node <NUM> may also facilitate a client to provision a physical server (without running as a VM). The examples described herein embody the provisioning of resources in the node <NUM> as part of a VM, however the technical solutions described can also be applied to provision the resources as part of a physical server.

In an example, the client devices 20A-20C may belong to the same entity, such as a person, a business, a government agency, a department within a company, or any other entity, and the node <NUM> may be operated as a private cloud of the entity. In this case, the node <NUM> solely hosts VMs 15A-15N that are deployed by the client devices 20A-20C that belong to the entity. In another example, the client devices 20A-20C may belong to distinct 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 node <NUM> may be operated as a public cloud that hosts VMs from different entities. For example, the VMs 15A-15N may be deployed in a shrouded manner in which the VM 15A does not facilitate access to the VM 15B. For example, the node <NUM> may shroud the VMs 15A-15N using an IBM z Systems® Processor Resource/Systems Manager (PR/SM) Logical Partition (LPAR) feature. These features, such as PR/SM LPAR provide isolation between partitions, thus facilitating the node <NUM> to deploy two or more VMs 15A-15N for different entities on the same physical node <NUM> in different logical partitions. A client device 20A from the client devices 20A-20C is a communication apparatus such as a computer, a smartphone, a tablet computer, a desktop computer, a laptop computer, a server computer, or any other communication apparatus that requests deployment of a VM by the hypervisor <NUM> of the node <NUM>. The client device 20A may send a request for receipt by the hypervisor via the network <NUM>. A VM 15A, from the VMs 15A-15N is a VM image that the hypervisor <NUM> deploys in response to a request from the client device 20A from the client devices 20A-20C. The hypervisor <NUM> is a VM monitor (VMM), which may be software, firmware, or hardware that creates and runs VMs. The hypervisor <NUM> facilitates the VM 15A to use the hardware components of the node <NUM> to execute programs and/or store data. With the appropriate features and modifications the hypervisor <NUM> may be IBM z Systems®, Oracle's VM Server, Citrix's XenServer, Vmware's ESX, Microsoft Hyper-V hypervisor, or any other hypervisor. The hypervisor <NUM> may be a native hypervisor executing on the node <NUM> directly, or a hosted hypervisor executing on another hypervisor. Turning now to <FIG>, a node <NUM> for implementing the teachings herein is shown in according to one or more embodiments of the invention. The node <NUM> can be an electronic, computer framework comprising and/or employing any number and combination of computing device and networks utilizing various communication technologies, as described herein. The node <NUM> can be easily scalable, extensible, and modular, with the ability to change to different services or reconfigure some features independently of others.

In this embodiment, the node <NUM> has a processor <NUM>, which can include one or more central processing units (CPUs) 901a, 901b, 901c, etc. The processor <NUM>, also referred to as a processing circuit, microprocessor, computing unit, is coupled via a system bus <NUM> to a system memory <NUM> and various other components. The system memory <NUM> includes read only memory (ROM) <NUM> and random access memory (RAM) <NUM>. The ROM <NUM> is coupled to the system bus <NUM> and may include a basic input/output system (BIOS), which controls certain basic functions of the node <NUM>. The RAM is read-write memory coupled to the system bus <NUM> for use by the processor <NUM>.

The node <NUM> of <FIG> includes a hard disk <NUM>, which is an example of a tangible storage medium readable executable by the processor <NUM>. The hard disk <NUM> stores software <NUM> and data <NUM>. The software <NUM> is stored as instructions for execution on the node <NUM> by the processor <NUM> (to perform process, such as the process flows of <FIG>. The data <NUM> includes a set of values of qualitative or quantitative variables organized in various data structures to support and be used by operations of the software <NUM>.

The node <NUM> of <FIG> includes one or more adapters (e.g., hard disk controllers, network adapters, graphics adapters, etc.) that interconnect and support communications between the processor <NUM>, the system memory <NUM>, the hard disk <NUM>, and other components of the node <NUM> (e.g., peripheral and external devices). In one or more embodiments of the present invention, the one or more adapters can be connected to one or more I/O buses that are connected to the system bus <NUM> via an intermediate bus bridge, and the one or more I/O buses can utilize common protocols, such as the Peripheral Component Interconnect (PCI).

As shown, the node <NUM> includes an interface adapter <NUM> interconnecting a keyboard <NUM>, a mouse <NUM>, a speaker <NUM>, and a microphone <NUM> to the system bus <NUM>. The node <NUM> includes a display adapter <NUM> interconnecting the system bus <NUM> to a display <NUM>. The display adapter <NUM> (and/or the processor <NUM>) can include a graphics controller to provide graphics performance, such as a display and management of a GUI <NUM>. A communications adapter <NUM> interconnects the system bus <NUM> with a network <NUM> enabling the node <NUM> to communicate with other systems, devices, data, and software, such as a server <NUM> and a database <NUM>. In one or more embodiments of the present invention, the operations of the software <NUM> and the data <NUM> can be implemented on the network <NUM> by the server <NUM> and the database <NUM>. For instance, the network <NUM>, the server <NUM>, and the database <NUM> can combine to provide internal iterations of the software <NUM> and the data <NUM> as a platform as a service, a software as a service, and/or infrastructure as a service (e.g., as a web application in a distributed system).

Thus, as configured in FIG. <NUM>, the operations of the software <NUM> and the data <NUM> (e.g., the node <NUM>) are necessarily rooted in the computational ability of the processor <NUM> and/or the server <NUM> to overcome and address the herein-described shortcomings of the conventional methods of dispatching VMs from encrypted images of the VMs.

Embodiments described herein are necessarily rooted in computer technology, and particularly computer servers that host VMs. Further, one or more embodiments of the present invention facilitate an improvement to the operation of computing technology itself, in particular computer servers that host VMs, by facilitating the computer servers that host VMs to host secure VMs, in which even the hypervisor is prohibited from accessing memory, registers, and other such data associated with the secure VM. In addition, one or more embodiments of the present invention provide significant steps towards the improvements of the VM hosting computing servers by using a secure interface control that includes hardware, firmware (e.g., millicode), or a combination thereof to facilitate a separation of the secure VM and the hypervisor, and thus maintaining a security of the VMs hosted by the computing server. The secure interface control provides lightweight intermediate operations to facilitate the security, without adding substantial overhead to securing VM state during initialization/exit of VMs as described herein.

Embodiments of the invention disclosed herein may include system, method, and/or computer program product (herein a system) that start a secure guest using an IPL mechanism. Note that, for each of explanation, identifiers for elements are reused for other similar elements of different figures.

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

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 number greater than or equal to one, i.e., one, two, three, four, etc. The terms "a plurality" may be understood to include any integer number greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" may include both an indirect "connection" and a direct "connection.

It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one more other features, integers, steps, operations, element components, and/or groups thereof.

Claim 1:
A method comprising:
receiving, by a hypervisor (<NUM>) that is executing on a host server, a request to dispatch a virtual machine (VM) (<NUM>) on the host server;
dispatching, by the hypervisor (<NUM>), the VM (<NUM>) on the host server, the VM (<NUM>) in a non-secure mode, the data of the VM (<NUM>) being accessible by the hypervisor, the VM including an encrypted image of the VM (<NUM>) and a reboot instruction that utilizes an initial program load (IPL) mechanism;
triggering, by the hypervisor (<NUM>), the reboot instruction to restart the VM (<NUM>) on the host server in a secure mode, the triggering comprising the hypervisor (<NUM>) calling a secure interface control to perform the restart of the VM (<NUM>) in the secure mode, the hypervisor (<NUM>) specifying a location of the encrypted image of the VM (<NUM>) on the host server (<NUM>) and decryption information; decrypting, by the secure interface control, the VM based on the decryption information and
performing the restart in response to the triggering, wherein subsequent to performing the restart, the hypervisor (<NUM>) is prevented from accessing any data of the VM (<NUM>).