HK40057635B - Starting a secure guest using an initial program load mechanism - Google Patents

Description

Start the secure client using the initial program loading mechanism.

Background Technology

This invention generally relates to computer technology, and more particularly to using the Initial Program Loading (IPL) mechanism to launch a secure client.

Cloud computing and storage provide users with the ability to store and process their data in third-party data centers. Cloud computing facilitates the ability to quickly and easily provision virtual machines (VMs) to customers without requiring them to purchase hardware or provide floor space for physical servers. Customers can scale VMs up or down based on their changing preferences or requirements. Typically, cloud providers provision VMs on servers that physically reside in the provider's data center. Customers are often concerned about the security of the data within VMs, especially since computing providers often store data from more than one customer on the same server. Customers may expect security between their code/data and the cloud provider, as well as between their code/data and the code/data of other VMs running at the provider's location. Furthermore, customers may expect security from the provider's administrators, and protection against potential security breaches in other code running on the machine.

To address this sensitive situation, cloud service providers can implement security controls to ensure proper data isolation and logical storage separation. The widespread use of virtualization in cloud infrastructure presents unique security challenges for customers of cloud services because virtualization alters the relationship between the operating system (OS) and the underlying hardware—whether computing, storage, or even networking. This introduces virtualization as an additional layer that itself must be properly configured, managed, and protected.

Summary of the Invention

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

According to an additional or alternative embodiment of the invention, the restart instruction utilizes the Initial Program Load (IPL) mechanism. Technical effects and benefits may include the ability to boot a secure VM using a standard IPL mechanism.

According to an additional or alternative embodiment of the invention, the dispatch includes loading an encrypted image of the VM into the host server's memory, and loading an unencrypted bootloader component including restart instructions into the memory. Technical effects and benefits may include the ability of the hypervisor to start the VM in insecure mode without first decrypting the VM image.

According to an additional or alternative embodiment of the invention, the dispatch also includes transferring control to the unencrypted bootloader component. Technical effects and benefits may include the ability of a hypervisor to start the VM in insecure mode without first decrypting the VM image and then transferring control to the bootloader component to restart the VM in secure mode.

According to additional or alternative embodiments of the invention, the VM includes encrypted components after dispatch. Technical effects and benefits may include the ability of the hypervisor to start the VM in insecure mode without first decrypting the VM image.

According to an additional or alternative embodiment of the invention, rebooting includes decrypting the encrypted components of the VM. Technical effects and benefits may include decrypting the encrypted VM image as part of the rebooting process.

According to an additional or alternative embodiment of the invention, the VM assigned by the hypervisor is in an insecure mode, and the VM's data is accessible to the hypervisor. Technical effects and benefits may include the ability of the hypervisor to start the VM in an insecure mode without first decrypting the VM's image.

According to additional or alternative embodiments of the invention, based on the determination that the VM is in the secure mode, the hypervisor is prevented from accessing any data of the VM. Technical effects and benefits may include the ability to provide a secure VM environment.

According to an additional or alternative embodiment of the invention, the VM on the host server includes an encrypted image of the VM. Furthermore, triggering the restart instruction includes the hypervisor invoking a security interface control to perform a restart in secure mode, the hypervisor specifying the location of the encrypted image of the VM on the host server and decryption information.

According to an additional or alternative embodiment of the invention, performing a restart includes decrypting the VM by a security interface control based on decryption information. It also includes restarting the VM based on the decrypted VM, wherein after the restart, the hypervisor is prevented from accessing any data of the VM.

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

Additional features and advantages are achieved through the technology of this invention. Other embodiments and aspects of the invention are described in detail herein and are considered part of this invention. For a better understanding of the advantages and features of the invention, please refer to the specification and accompanying drawings.

Attached Figure Description

The proprietary details described herein are specifically pointed out and clearly claimed in the claims at the end of the specification. The foregoing and other features and advantages of embodiments of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein:

Figure 1 illustrates a schematic diagram of a system for starting a client using an Initial Program Loading (IPL) mechanism according to one or more embodiments of the present invention;

Figure 2 depicts a flowchart of a process for launching a secure client using an Initial Program Loading (IPL) mechanism according to one or more embodiments of the present invention;

Figure 3 illustrates a schematic diagram of a system including a secure client loaded on a host server according to one or more embodiments of the present invention;

Figure 4 depicts an IPL information block for launching a secure client according to one or more embodiments of the present invention;

Figure 5 illustrates a process flow for launching a secure client according to one or more embodiments of the present invention;

Figure 6 depicts a cloud computing environment according to one or more embodiments of the present invention;

Figure 7 depicts an abstract model layer according to one or more embodiments of the present invention;

Figure 8 depicts a system according to one or more embodiments of the present invention; and

Figure 9 depicts a processing system according to one or more embodiments of the present invention.

The figures described herein are illustrative. Many variations may be made to the figures or operations described herein without departing from the spirit of the invention. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "coupled" and its variations describe a communication path between two elements and do not imply a direct connection between the elements without any intermediate elements/connections between them. All such variations are considered part of the specification.

Detailed Implementation

According to one or more embodiments of the present invention, a novel Initial Program Loading (IPL) mechanism is provided to allow a client or virtual machine (VM) executing on a host server to request transition to a safe mode. When in safe mode, the hypervisor cannot access the VM's data. According to one or more embodiments of the present invention, when the VM is executing in safe mode, security interface controls implemented in hardware and/or firmware are used to provide isolation between the secure client and other clients executing on the host server.

According to one or more embodiments of the present invention, an encrypted image of a virtual machine (VM) is loaded into the VM storage of a host server along with an unencrypted bootloader component. The bootloader component can access information about all storage pages of the encrypted image of the VM, as well as the metadata structure, for use when decrypting the image and for restarting the VM in secure mode (i.e., as a secure client). According to one or more embodiments of the present invention, the metadata structure also includes a list of contiguous regions of the operating system image that can be used. As is known in the art, instead of listing all storage pages of the operating system separately, a list of regions including the starting page and page number can save space and speed up processing. For example, if the assumed operating system image resides in pages 0, 1, 2, 3, 6, and 7, this can be specified as (0, 4) and (6, 2).

According to one or more embodiments of the present invention, the bootloader component triggers a reboot or restart operation by preparing a new formatted IPL information block; sets the IPL information block using, for example, "Diagnostic 308 Subcode 5"; and executes the IPL using, for example, "Diagnostic 308 Subcode 3" or a new code. The IPL information block may include: a Secure Execution (SE) header with an image key and integrity value; a list of memory regions to be decrypted; and an Initialization Vector (IV) that has been used for all pages of the encrypted image. In conventional environments, the IPL information block contains an identifier of the boot source, which may be a disk device address, a CD-ROM-like name, etc. For a secure environment implemented by one or more embodiments of the present invention, the boot source identification information includes an encryption key and the memory regions to be decrypted. Depending on the encryption method used, one or more embodiments of the present invention implement an IV to increase the randomness of the encryption. A unique IV may be provided for each of the memory regions. This type of encryption method utilizing 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 different IVs, the encrypted contents will be different, making it impossible for an adversary to know that the contents are the same.

"Diagnostics" is an example of instructions that allow the guest operating system to interact with the hypervisor. Diagnostic instructions are used by IBM z, and Diagnostics 308 is specifically designed for the IPL (Initial Boot Processor) operation during program boot. Subcode 5 is used to set IPL parameters (such as the boot device to use), while subcode 3 is used to trigger a reboot from the boot device previously specified by subcode 5. The mechanism for requesting a reboot from within the operating system is architecture-dependent. On some x86 machines, commercially available software tools can be used to change the boot device.

According to one or more embodiments of the present invention, the hypervisor uses information from the IPL information block, including the SE header of the security interface control (also referred to herein as the "super monitor"), to create a secure client configuration and perform unpacking or decryption of the encrypted VM image. If unpacking is successful, the unpacked VM gains control and executes in secure mode. If unpacking fails, the VM enters a disabled wait state in insecure mode.

A VM running as a guest under the control of a hypervisor relies on that hypervisor to transparently provide virtualization services to the guest. These services can be applied to any interface between a secure entity and another untrusted entity that traditionally allows that other entity to access secure resources. These services can include, but are not limited to, memory management, instruction emulation, and interrupt handling. For example, for interrupt and exception injection, the hypervisor typically reads and/or writes to the guest's prefix region (low core). As used herein, the term "virtual machine" or "VM" refers to the logical representation of a physical machine (computing device, processor, etc.) and its processing environment (operating system (OS), software resources, etc.). A VM is maintained as software executing on the underlying host (physical processor or processor group). From the perspective of a user or software resource, a VM appears as its own independent physical machine. The terms "hypervisor" and "VM monitor (VMM)" as used herein refer to the processing environment or platform services that manage and allow multiple VMs to run on the same host using multiple (sometimes different) OSes. It should be understood that deploying a VM includes both the VM installation process and the VM activation (or startup) process. In another example, deploying a VM includes the activation (or startup) process of the VM (e.g., if the VM has been pre-installed or already exists).

However, in order to facilitate secure clients, there are technical challenges in situations where additional security is required between the hypervisor and the secure client, preventing the hypervisor from accessing data from the VM and thus preventing the provision of services such as those mentioned above.

In currently available technologies, a hypervisor (e.g., a virtual machine (KVM) powered by or based on an open-source software kernel) starts a new VM on a physical processing unit or host server by issuing a Start Interpreted Execution (SIE) instruction. A portion of the VM's state and its characteristics are stored in a control block (as a state description or "SD") pointed to by the operand (typically the second operand) of the SIE instruction. In this case, the hypervisor has control over the VM's data, and in some cases, this control is required to interpret the instructions executed on the VM. Existing hypervisors rely on using such an interface via SIE instructions to start VMs.

The secure execution described herein provides a hardware mechanism to ensure isolation between secure and insecure storage devices, as well as between secure storage devices belonging to different secure users. For the secure client, additional security is provided between the "untrusted" hypervisor and the secure client. To do this, many functions that the hypervisor typically performs on behalf of the client need to be integrated into the machine. A secure interface control provides a secure interface between the hypervisor and the secure client. The secure interface control works in conjunction with the hardware to provide this additional security. The term Super Monitor (UV) used herein refers to an example of a secure interface control that can be implemented by one or more embodiments of the present invention.

In one example, the security interface control is implemented internally in secure and trusted hardware and/or firmware. For secure clients or entities, the security interface control provides the initialization and maintenance of the secure environment and the coordination of the distribution of these secure entities on the hardware. When a secure client is actively using data and it resides in the host storage device, it is held "unhindered" in secure storage. The secure storage device can be accessed by that single secure client, which is strictly enforced by the hardware. That is, the security interface control prevents any non-secure entity (including hypervisors or other non-secure clients) or different secure clients from accessing the data. In this example, the security interface control operates as a trusted part of the lowest-level firmware. The lowest level, or millicode, is essentially an extension of the hardware and is used to implement the complex instructions and functions defined in the z/ architecture. Millicode can access all parts of the storage device, which, in the context of secure execution, includes its own secure UV storage device, non-secure hypervisor storage device, secure client storage device, and shared storage device. This allows it to provide any functionality required by the secure client or the hypervisor supporting that client. The security interface control also has direct access to the hardware, which allows the hardware to effectively provide security checks under the control of conditions established by the security interface control.

One or more embodiments of the present invention provide a technical improvement over existing systems that utilize encrypted VM images. Existing systems decrypt the encrypted VM image before booting the VM on the host machine. A disadvantage of this approach is that dedicated computer instructions are required in the hypervisor to determine whether the VM image is encrypted and to perform decryption before dispatching or booting the VM on the host. One or more embodiments of the present invention do not require updating the hypervisor dispatch code, or require the hypervisor to know that the VM image is encrypted before the VM boots on the host machine. Furthermore, the hypervisor can be used to boot a secure VM, even after the secure VM has been booted, the hypervisor cannot access any data of the secure VM.

One or more embodiments of the present invention provide technical improvements to existing systems by providing a secure environment for executing VMs on a host server hosting multiple 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 client running on a host machine.

Turning now to Figure 1, a schematic diagram of a system 100 for booting a secure client using an IPL mechanism is generally shown according to one or more embodiments of the present invention. The system 100 shown in Figure 1 includes a client address space 102 of a host server, a host disk including a Basic Input/Output System (BIOS) 104 or loader, and a client disk storing the operating system components of the secure client. The terms "client" and "virtual machine" or "VM" are used interchangeably herein. The operating system components of the secure client shown in Figure 1 include an unencrypted bootloader component 106 and an encrypted image 108 of the client. According to one or more embodiments of the present invention, a hypervisor executing on the host server is instructed to load the client into the client address space 102. The hypervisor receives information about where the client image is located on the client disk in this case and boots the BIOS 104 to load the operating system components into the client address space 102.

When BIOS 104 finishes loading the operating system components into the guest address space 102, the guest appears as an insecure guest to the hypervisor. The hypervisor is unaware that the guest image is encrypted and currently inoperable. The hypervisor transfers control to the bootloader component 106 at the specified address, which triggers an Initial Program Load (IPL) or reboot of the guest in safe mode by the supermonitor. In the IBM implementation, the disk containing the operating system components contains a hidden boot image file that describes where the components reside on the disk, which memory locations they must be loaded into, and the address of the first instruction to be executed after the initial load is complete (i.e., the starting address of the bootloader component). One or more embodiments may be implemented by other architectures that may have a fixed memory address for initiating the execution of the operating system.

As shown in Figure 1, the bootloader component 106 includes bootloader code executed by the hypervisor to trigger a transition to safe mode, and an SE header including metadata used by the super monitor to decrypt the encrypted image of the client 108.

Turning now to Figure 2, a flowchart of a process 200 for booting a secure client using an Initial Program Load (IPL) mechanism is generally shown according to one or more embodiments of the invention. The process shown in Figure 2 can be performed by a combination of a hypervisor and a super monitor executed on the host machine. The process shown in Figure 2 is performed after the operating system components (e.g., encrypted images of the client 108 and bootloader component 106 of Figure 1) have been loaded into the host server's memory (e.g., the client address space 102 of Figure 1) and control has been transferred to the bootloader component.

In box 202, the client (e.g., bootloader code running in the client) invokes the hypervisor to set IPL parameters. IPL parameters may include, but are not limited to, the SE header, memory regions, and initialization vectors (IVs) for decryption. As used herein, the term "SE header" refers to a data structure containing sensitive information about the operating system, such as a key used to decrypt the operating system image. Because this information is sensitive, portions of the SE header must be encrypted so that only the security control interface can decrypt this data in the SE header. The memory regions specify which memory regions(s) in the encrypted image need to be decrypted. According to one or more embodiments of the invention, a private/public key pair is used to perform 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 supermonitor. One or more embodiments of the invention can implement any encryption/decryption scheme known in the art, and the private/public key pair is merely one example of a possible scheme. Because the key contained in the SE header is protected, the image encryption key can also be a symmetric key (and is also used for decryption).

In box 204 of Figure 2, the hypervisor determines whether the IPL parameters are valid. Validation may include checking the presence of the SE header, the presence of at least one memory region, and ensuring that multiple memory regions do not overlap. In box 204, the hypervisor performs a validity check and stores the parameters in a memory location owned by the hypervisor and inaccessible to the client. Therefore, the presence of the parameters is a sufficient indication of their validity.

If it is determined in box 206 that the IPL parameter is invalid, processing continues in box 206, and the client continues to execute in non-secure mode. If it is determined in box 206 that the IPL parameter is valid, processing continues in box 208, where the client invokes the hypervisor to perform a restart. In box 210, the hypervisor verifies that the IPL parameter has been provided and checked.

If it is determined in box 210 of Figure 2 that the IPL parameters have not yet been provided and checked, the process continues in box 206, and the client continues to execute in insecure mode. If it is determined in box 210 that the IPL parameters have been provided and checked, the process continues in box 212. In box 212, the hypervisor invokes the super monitor to create a secure client configuration, unpacks (e.g., decrypts) the encrypted image, and begins secure execution of the client. In box 214, it is determined whether the image has been successfully decrypted and optionally verified. According to one or more embodiments of the invention, decryption is verified by comparing a checksum or hash calculated on the image with a checksum stored in the SE header. If the image is decrypted and verified, the process continues in box 216, where the client runs in secure mode (i.e., as a secure client) under the control of the super monitor. If the image is not decrypted and verified, the process continues in box 218, where the client enters a disabled waiting state in insecure mode.

Turning now to Figure 3, a schematic diagram of a system 300 comprising a secure client loaded on a host server is generally shown according to one or more embodiments of the invention. The system 300 shown in Figure 3 depicts the state of system 100 of Figure 1 after the encrypted image has been decrypted and the secure system has been booted on the host machine using a process such as that shown in Figure 2. As shown in Figure 3, an unencrypted version of image 308 is loaded into the client address space 102, and control has been given to the client's kernel to boot the secure client.

Turning now to Figure 4, a schematic diagram of an IPL information block 400 for booting a secure client is generally shown according to one or more embodiments of the invention. The overall layout of the IPL information block shown in block 402 is a typical IPL block layout, including fields specifying: the length of the block (e.g., in bytes); a version number; a parameter block for loading device information, such as a disk device address, a generic boot device name like "CDROM," or a network address; and a parameter block for attaching System Control Parameters (SCP) data, which can be used if the boot method requires parameters that are not suitable for the first part of the information block. In addition to including a type field for the memory (along with disks, networks, etc.) of the new type of IPL being executed, according to one or more embodiments of the invention, the parameter block for loading device information 404 is also a typical IPL block layout. This allows the IPL to load data from the memory of the host server where the encrypted VM image resides. Furthermore, the loading device-specific parameter block includes a new type of information used by the hypervisor to perform decryption: an SE header 406 with information for performing decryption; and image information 408, which may include information describing the structure of the image in memory.

Turning now to Figure 5, a general process flow 500 for launching a secure client is illustrated according to one or more embodiments of the present invention. The process shown in Figure 5 can be performed by a hypervisor running on a host server. In block 502, the hypervisor running on the host server receives a request to dispatch a VM on the host server. In block 504, the VM is dispatched on the host server in an insecure mode. When the VM is in insecure mode, the VM's data is accessible to the hypervisor. The VM includes a bootloader component containing restart instructions for restarting the VM. According to one or more embodiments of the present invention, the dispatch includes loading an encrypted image of the VM into the host server's memory and loading an unencrypted bootloader component including the restart instructions into memory. The dispatch also includes transferring control to the bootloader component.

In box 506, according to one or more embodiments of the invention, a secure reboot is initiated by a bootloader component. The bootloader component (1) sets IPL information and (2) requests a reboot. The hypervisor intercepts both (1) and (2), and in response to (2), the hypervisor transfers control to the supermonitor for decryption. When decryption is complete, the supermonitor bypasses the hypervisor and transfers control to the now secure client. According to one or more embodiments of the invention, the reboot includes decrypting encrypted components of the VM. When the VM is in secure mode, the hypervisor is prevented from accessing any data of the VM.

It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

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 power, storage, applications, virtual machines, and services) can be rapidly deployed and released with minimal management costs or minimal interaction with service providers. This cloud model can include at least five features, at least three service models, and at least four deployment models.

The characteristics are as follows:

On-demand self-service: Cloud consumers can unilaterally and automatically deploy computing power, such as server time and network storage, on demand without having to interact with service providers.

Extensive network access: Computing power is obtained through the network and accessed through standard mechanisms that facilitate use across various types of thin client or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pool: A provider's computing resources are grouped into a resource pool to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers typically do not control or know the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center), thus exhibiting location independence.

Rapid and elastic: Computing power can be deployed quickly and elastically (sometimes automatically) to scale up rapidly and shrink quickly. For consumers, the available computing power for deployment often appears unlimited, and any amount of computing power can be obtained at any time.

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

The service model is as follows:

Software as a Service (SaaS): The capability offered to consumers is the ability to use applications running on a provider's cloud infrastructure. Applications can be accessed from a variety of client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers neither manage nor control the underlying cloud infrastructure, including the network, servers, operating system, storage, and even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications on cloud infrastructure, 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 they can control the deployed applications and, if any, the configuration of the application hosting environment.

Infrastructure as a Service (IaaS): This provides consumers with the ability to deploy processing, storage, networking, 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 rather have control over the operating system, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

The deployment model is as follows:

Private cloud: A cloud infrastructure that operates independently for an organization. It can be managed by the organization or a third party, and can exist inside or outside the organization.

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

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

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 applications to be ported together (e.g., cloud burst traffic balancing for load balancing between clouds).

Cloud computing environments are service-oriented, characterized by statelessness, loose coupling, modularity, and semantic interoperability. At its core is the infrastructure comprising a network of interconnected nodes.

Referring now to Figure 6, an illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 that a cloud consumer can communicate with 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. Nodes 10 can communicate with each other. They can be physically or virtually grouped in one or more networks (not shown), such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations 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 maintaining resources on their local computing devices. It should be understood that the types of computing devices 54A-N shown in Figure 6 are merely illustrative, and the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computing device (e.g., using a web browser) via any type of network and/or network-addressable connectivity.

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

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

The virtual layer 70 provides an abstraction layer from which examples of the following virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73 (including virtual private network); virtual application and operating system 74; and virtual client 75.

In one example, management layer 80 can provide the functions described below: Resource provisioning function 81 provides dynamic acquisition of computing resources and other resources for performing tasks within the cloud computing environment. 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. Security function provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal function 83 provides access to the cloud computing environment for consumers and system administrators. Service level management function 84 provides allocation and management of cloud computing resources to meet required service levels. Service Level Agreement (SLA) planning and fulfillment function 85 provides pre-scheduling and provisioning of future cloud computing resource needs projected according to the SLA.

Workload layer 90 provides examples of functionalities that can leverage a cloud computing environment. Examples of workloads and functionalities that may be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom instruction delivery 93; data analytics and processing 94; transaction processing 95; and dispatching secure clients 96. It is understood that these are merely examples, and in other embodiments, these layers may include different services.

Turning now to Figure 8, a system 800 is depicted according to one or more embodiments of the present invention. System 800 includes an example node 10 (e.g., a managed node) that communicates with one or more client devices 20A-20C via a network 165. Node 10 may be a data center or host server of a cloud computing provider. Node 10 executes a hypervisor 12, which facilitates the deployment of one or more VMs 15 (15A-15N). Node 10 also includes a hardware/firmware layer 11, which facilitates the hypervisor 12 providing one or more services to the VMs 15. In prior art, there is communication between the hypervisor 12 and the hardware/firmware layer 11; communication between the hardware/firmware layer 11 and one or more VMs 15; communication between the hypervisor 12 and one or more VMs 15; and communication from the hypervisor 12 to the VMs 15 via the hardware/firmware layer 11. To facilitate a secure VM environment, the managed 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.

For example, node 10 can facilitate the deployment of one or more VMs 15A-15N by client device 20A. VMs 15A-15N can be deployed in response to corresponding requests from different client devices 20A-20C. For example, VM 15A can be deployed by client device 20A, VM 15B can be deployed by client device 20B, and VM 15C can be deployed by client device 20C. Node 10 can also facilitate clients provisioning physical servers (not running as VMs). The examples described herein embody resource provisioning in node 10 as part of VMs; however, the described techniques can also be applied to provisioning resources as part of physical servers.

In one example, client devices 20A-20C can belong to the same entity, such as an individual, enterprise, government agency, department within a company, or any other entity, and node 10 can operate as a private cloud for that entity. In this case, node 10 hosts VMs 15A-15N deployed by client devices 20A-20C belonging to that entity. In another example, client devices 20A-20C can belong to different entities. For example, a first entity could own client device 20A, while a second entity could own client device 20B. In this case, node 10 can operate as a public cloud hosting VMs from different entities. For example, VMs 15A-15N can be deployed in a shielded manner where VM 15A does not facilitate access to VM 15B. For example, node 10 can use the IBM z Processor Resource/System Manager (PR/SM) Logical Partition (LPAR) feature to override VMs 15A-15N. These features, such as PR/SM LPAR, provide isolation between partitions, thereby enabling node 10 to deploy two or more VM15A-15Ns for different entities on the same physical node 10 in different logical partitions.

Client device 20A from client devices 20A-20C is a communication device, such as a computer, smartphone, tablet computer, desktop computer, laptop computer, server computer, or any other communication device requesting the deployment of a VM by the hypervisor 12 of node 10. Client device 20A may send requests via network 165 for the hypervisor to receive. VM 15A in VMs 15A-15N is a VM image deployed by the hypervisor 12 in response to a request from client device 20A from client devices 20A-20C. Hypervisor 12 is a VM monitor (VMM), which may be the software, firmware, or hardware that creates and runs the VM. Hypervisor 12 facilitates the VM 15A's use of the hardware components of node 10 to execute programs and/or store data. With appropriate features and modifications, hypervisor 12 may be an IBM or Oracle VM server, Citrix XenServer, VMware ESX, Microsoft Hyper-V hypervisor, or any other hypervisor. The management program 12 may be a native management program that executes directly on node 10, or a managed management program that executes on another management program. Turning now to Figure 9, a node 10 is illustrated for implementing the teachings herein, according to one or more embodiments of the invention. Node 10 may be an electronic computer framework that includes and/or employs any number of computing devices as described herein and networks and combinations thereof utilizing various communication technologies. Node 10 may be easily scalable, extensible, and modular, with the ability to change to different services or reconfigure some features independently of others.

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

Node 10 in Figure 9 includes a hard disk 907, which is an example of a tangible storage medium executable by processor 901. Hard disk 907 stores software 908 and data 909. Software 908 is stored as instructions executable by processor 901 on node 10 to perform processing such as the processing flow shown in Figures 1-9. Data 909 includes the values of a set of qualitative or quantitative variables organized in various data structures to support and be used by the software 908.

Node 10 in Figure 9 includes one or more adapters (e.g., hard disk controller, network adapter, graphics adapter, etc.) that interconnect and support communication between processor 901, system memory 903, hard disk 907, and other components of node 10 (e.g., peripherals and external devices). In one or more embodiments of the invention, the one or more adapters may be connected to one or more I/O buses that are connected to system bus 902 via an intermediate bus bridge, and the one or more I/O buses may utilize common protocols such as Peripheral Component Interconnect (PCI).

As shown in the figure, node 10 includes an interface adapter 920 that interconnects a keyboard 921, mouse 922, speaker 923, and microphone 924 to a system bus 902. Node 10 also includes a display adapter 930 that interconnects the system bus 902 to a display 931. The display adapter 930 (and/or processor 901) may include a graphics controller to provide graphics performance, such as the display and management of a GUI 932. A communication adapter 941 interconnects the system bus 902 to a network 950, enabling node 10 to communicate with other systems, devices, data, and software, such as server 951 and database 952. In one or more embodiments of the invention, the operation of software 908 and data 909 may be implemented on network 950 by server 951 and database 952. For example, network 950, server 951, and database 952 may be combined to provide internal iterations of software 908 and data 909 as a platform as a service, software as a service, and/or infrastructure as a service (e.g., as a network application in a distributed system).

Therefore, as configured in Figure 9, the operation of software 908 and data 909 (e.g., node 10) is necessarily rooted in the computing power of processor 901 and/or server 951 to overcome and resolve the shortcomings of the conventional method of allocating VMs based on encrypted images of VMs as described herein.

The embodiments described herein are necessarily rooted in computer technology, particularly computer servers hosting virtual machines (VMs). Furthermore, one or more embodiments of the invention facilitate improvements to the operation of computing technology itself, particularly computer servers hosting VMs, by enabling computer servers hosting secure VMs, where even the hypervisor is prohibited from accessing memory, registers, and other such data associated with the secure VM. Additionally, one or more embodiments of the invention provide an important step toward improvements to VMs hosted on computing servers by using secure interface controls, including hardware, firmware (e.g., microcode), or a combination thereof, to facilitate the separation of the secure VM and the hypervisor, and thus maintain the security of the VM hosted by the computing server. The secure interface controls provide lightweight intermediate operations to facilitate security without adding the substantial overhead of protecting the VM state during VM initialization/exit as described herein.

The embodiments of the invention disclosed herein may include systems, methods, and/or computer program products (here, systems) that use an IPL mechanism to launch a secure client. Note that for each description, the identifiers of elements are repeated for other similar elements in different figures.

Various embodiments of the invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be devised without departing from the scope thereof. In the following description and drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are illustrated between elements. Unless otherwise stated, these connections and/or positional relationships may be direct or indirect, and the invention is not intended to be limiting in this respect. Therefore, coupling of entities may refer to direct or indirect coupling, and positional relationships between entities may be direct or indirect positional relationships. Furthermore, the 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.

The following definitions and abbreviations are used to interpret the claims and specification. As used herein, the terms “comprising,” “including,” “having,” “containing,” or any other variations thereof are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such compositions, mixtures, processes, methods, articles, or apparatus.

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

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

This invention can 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 aspects of the invention.

Computer-readable storage media can be tangible devices that can retain and store instructions for use by instruction execution devices. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed protrusions on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage media used herein should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses transmitted through fiber optic cables), or electrical signals transmitted through wires.

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

Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be personalized using status information from the computer-readable program instructions, which execute the computer-readable program instructions to perform aspects of the invention.

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

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 apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/actions specified in the flowchart and/or one or more block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and/or other device to operate in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of writing comprising instructions for implementing aspects of the functions/actions specified in the flowchart and/or one or more block diagram blocks.

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

The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, program segment, or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may not occur in the order shown in the figures. For example, two blocks shown consecutively may actually be executed substantially in parallel, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may 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.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that, when used in this specification, the terms “comprising” and/or “including” specify the presence of the stated features, integers, steps, operations, elements, and/or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or combinations thereof.

This document has presented descriptions of various embodiments for illustrative purposes, but it is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements to existing technologies on the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims (18)

1. A method for launching a secure client, comprising: The hypervisor, which runs on the host server, receives a request to assign a virtual machine (VM) on the host server. The management program assigns the VM to the host server, wherein the VM is in an insecure mode and includes an encrypted image of the VM and a restart instruction that utilizes the initial program to load the IPL mechanism; The management program triggers the restart command to restart the VM on the host server in safe mode, wherein the triggering includes: the management program invoking a security interface control to perform the restart in safe mode, and the management program specifying the location of the encrypted image of the VM on the host server and decryption information; and In response to triggering a restart, the hypervisor is prevented from accessing any data in the VM after the restart is performed. 2. The method according to claim 1, wherein the assignment comprises: Load the encrypted image of the VM into the host server's memory; and The unencrypted bootloader component, including the reboot command, is loaded into the memory. 3. The method of claim 2, wherein the dispatch further includes transferring control to the unencrypted bootloader component. 4. The method according to any one of claims 1-3, wherein, after the dispatch, the VM includes an encrypted component. 5. The method of claim 4, wherein the restart includes decrypting the encrypted component of the VM. 6. The method according to any one of claims 1-3, wherein when the VM assigned by the management program is in an insecure mode, the data of the VM can be accessed by the management program. 7. The method according to any one of claims 1-3, wherein, based on determining that the VM is in the security mode, the hypervisor is prevented from accessing any data of the VM. 8. The method of claim 1, wherein performing the restart comprises: The security interface control decrypts the VM based on the decryption information; and Reboot the VM based on the decrypted VM. 9. A system for launching a secure client, comprising: Memory; Security interface controls; and A processing unit coupled to the memory and the security interface control is configured to execute a hypervisor that hosts multiple virtual machines (VMs). When the VMs are in a secure mode, the hypervisor is prohibited from directly accessing any data of the VMs, and the hypervisor is configured to perform: The hypervisor, which runs on the host server, receives a request to assign a VM on the host server. The management program assigns the VM to the host server. The VM is in an insecure mode and includes an encrypted image of the VM and a restart command that utilizes the initial program to load the IPL mechanism. The management program triggers the restart command to restart the VM on the host server in safe mode, wherein the triggering includes: the management program invoking a security interface control to perform the restart in safe mode, and the management program specifying the location of the encrypted image of the VM on the host server and decryption information; and In response to triggering a restart, the hypervisor is prevented from accessing any data in the VM after the restart is performed. 10. The system of claim 9, wherein the dispatching comprises: Load the encrypted image of the VM into the host server's memory; and The unencrypted bootloader component, including the reboot command, is loaded into the memory. 11. The system of claim 10, wherein the dispatch further includes transferring control to the unencrypted bootloader component. 12. The system according to any one of claims 9 to 11, wherein, after the dispatch, the VM includes an encrypted component. 13. The system of claim 12, wherein the restart includes decrypting the encrypted component of the VM. 14. The system according to any one of claims 9 to 11, wherein when the VM assigned by the management program is in an insecure mode, the data of the VM can be accessed by the management program. 15. A computer program product comprising a computer-readable storage medium, the computer-readable storage medium including computer-executable instructions, the computer-executable instructions causing the processing unit to perform a method when executed by a processing unit, the method comprising: The hypervisor, which runs on the host server, receives a request to assign a virtual machine (VM) on the host server. The management program assigns the VM to the host server, wherein the VM is in an insecure mode and includes an encrypted image of the VM and a restart instruction that utilizes the initial program to load the IPL mechanism; The management program triggers the restart command to restart the VM on the host server in safe mode, wherein the triggering includes: the management program invoking a security interface control to perform the restart in safe mode, and the management program specifying the location of the encrypted image of the VM on the host server and decryption information; and In response to triggering a restart, the hypervisor is prevented from accessing any data in the VM after the restart is performed. 16. The computer program product of claim 15, wherein the dispatch comprises: Load the encrypted image of the VM into the host server's memory; and The unencrypted bootloader component, including the reboot command, is loaded into the memory. 17. The computer program product of claim 16, wherein the dispatch further includes transferring control to the unencrypted bootloader component. 18. The computer program product according to any one of claims 15 to 17, wherein, after the dispatch, the VM includes an encrypted component, and the restart includes decrypting the encrypted component of the VM.