HK40057235A - Inject interrupts and exceptions into secure virtual machine - Google Patents

Description

Injection interrupts and exceptions in secure virtual machines

Background

The present application relates to computer technology, and more particularly, to virtual machines or containers.

Cloud computing facilitates the ability to quickly and easily provision virtual machines to customers without requiring the customer to purchase hardware or provide ground space for physical servers. The guest may expand or contract the virtual machine according to changing preferences. Typically, cloud computing providers provision virtual machines that physically reside at the provider's data center. In this environment, a customer's virtual machine runs as a client, and a cloud provider uses hypervisor code running as a host to virtualize server resources among multiple virtual machines that may belong to different customers.

Customers are often concerned with the security of data in virtual machines. Customers may desire security between their code, data, cloud computing providers, or their data, code, and data with other Virtual Machines (VMs) from running at the provider's site. The customer may desire security from the provider's administrator as well as prevent potential security holes in other code running on the machine, including hypervisor code. These administrators and other code may be acting with malicious intent.

Typically, a Virtual Machine (VM) running as a client under the control of a host hypervisor relies on the hypervisor to transparently provide virtualization services for the client. These services include memory management, instruction emulation, and interrupt handling.

Disclosure of Invention

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

According to one or more embodiments of the invention, the method further comprises prior to the injecting, controlling by the secure interface whether the injection of the interrupt into the secure entity is allowed, wherein the injecting is performed based on the determining that the injection of the interrupt into the secure entity is allowed. In one or more examples, the secure interface control determines that the interrupt is allowed to be injected into the secure entity based on a predetermined list of allowable interrupts for the secure entity. The list of permission interruptions is specific to the secure entity.

According to one or more embodiments of the invention, the information about the interrupt comprises an identifier of the interrupt to be injected and one or more parameters associated with the interrupt. In one or more examples, the method further comprises: prior to the injection, determining, by the safety interface control, whether to allow injection of the interrupt and the one or more parameters into the safety entity, wherein the injection is performed based on determining that the interrupt and the one or more parameters are allowed to be injected into the safety entity.

In one or more examples, the method further includes deallocating a processor associated with the secure entity prior to injection by the non-secure entity. Further, after the information about the interrupt is added by the non-secure entity, the virtual processor is reallocated to resume operation of the secure entity.

According to one or more embodiments of the invention, the method further comprises: indicating, by the secure interface control, an error to the non-secure entity in response to determining that the interrupt is not permitted to be injected into the secure entity.

According to one or more embodiments of the invention, the secure interface control includes hardware, millicode, and other trusted firmware.

Further, in accordance with one or more embodiments of the present invention, a computer-implemented method comprises: executed by a secure entity executing on a non-secure entity on a host server, generating instructions of a condition to be forwarded to the non-secure entity, the non-secure entity being prohibited from directly accessing any data not explicitly shared by the secure entity of the secure entity. The method further includes deporting the processor associated with the secure entity executing the instruction, the non-secure entity then emulating the instruction. The method also includes determining, by the non-secure entity, whether the interrupt or program exception should be delivered to the secure entity, and based on such determination, injecting the interrupt or program exception into the secure entity. The injection interruption comprises: based on an interrupt or program exception raised by emulation of an instruction, information about the interrupt or program exception is added by the non-secure entity to a portion of the non-secure storage associated with the secure entity. Injecting the interrupt further includes resuming a processor associated with the secure entity to resume operation of the secure entity.

In accordance with one or more embodiments of the invention, the method further includes determining, by the security interface control, whether the program exception is valid for injecting the security entity prior to the injecting, wherein the injecting is performed based on determining that the program exception is valid for injecting the security entity. In one or more examples, the secure interface control determines that the program exception is valid based on a predetermined exception list corresponding to the instruction. In one or more examples, the information regarding the program exception includes an identifier of the program exception to be injected and one or more parameters associated with the program exception.

The above-described features may also be provided at least by a system, a computer program product, and a machine.

Additional technical features and benefits are realized through the techniques of the present invention. Embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, reference should be made to the detailed description and accompanying drawings.

Drawings

The details of the exclusive right described herein are set forth with particularity in the appended claims of the specification and are clearly claimed. The foregoing and other features and advantages of embodiments of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 depicts a cloud computing environment according to an embodiment of the invention;

FIG. 2 depicts abstraction model layers according to an embodiment of the invention;

FIG. 3 illustrates an example system for a host system, according to an embodiment;

FIG. 4 illustrates an example block diagram of a host system, according to an embodiment;

FIG. 5 sets forth a flow chart illustrating an exemplary method for secure interface control to provide notification of an interrupt to a secure Virtual Machine (VM) according to one or more embodiments of the present invention;

FIG. 6 sets forth a flow chart illustrating an exemplary method for a secure Virtual Machine (VM) causing an exception in a non-secure entity according to one or more embodiments of the present invention.

Detailed Description

Various embodiments of the present invention are described herein with reference to the associated drawings. Alternative embodiments of the invention may be devised without departing from the scope thereof. Various connections and positional relationships (e.g., above, below, adjacent, etc.) are set forth between elements in the following description and drawings. These connections and/or positional relationships may be direct or indirect unless otherwise specified, and the invention is not intended to be limited in this respect. Thus, coupling of entities may refer to direct or indirect coupling, and positional relationships between entities may be direct or indirect positional relationships. In addition, various tasks and process steps described herein may be incorporated into a more comprehensive procedure or process having additional steps or functions not described in detail herein.

The following definitions and abbreviations are used to interpret the claims and description. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains" or "containing" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

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

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

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

A technical challenge with typical cloud environments is potentially insecure and unwanted access to Virtual Machine (VM) data and algorithms (e.g., by a cloud provider or cloud administrator). Cloud providers typically run hypervisor code as a host, while the guest's Virtual Machines (VMs) run as guests. The hypervisor code provides the virtualization functionality needed to allow multiple Virtual Machines (VMs) to run on a single physical machine. In existing systems, the hypervisor (and typically by extending the cloud administrator) has access to the customer's data and algorithms for the case where it must access a limited portion of that data to provide virtualization functionality. One example of virtualization is the handling of I/O operations by a hypervisor. This is required due to the complexity of virtualizing I/O operations for a large number of virtualized clients. The first part of the virtualization begins when the client issues an I/O instruction, such as I/O request x, to initiate a request. This requires the hypervisor to access the client operands (both registers and memory) of the I/O instruction. In response to the instruction, the hypervisor updates the appropriate control block structure to track the request and initiate the I/O request in hardware. Those control block structures may be used by the hardware/firmware to present the associated I/O interrupt x directly to the client machine (if it is dispatched). However, if the enabled wait state is entered while waiting for the I/O request of a client to complete, the hypervisor may dispatch another client on the hardware that does have work to do, since the client does nothing. To do this, the hypervisor monitors (with the help of hardware/firmware) when an I/O interrupt x becomes pending and presents it to the client and reschedules the client when applicable from a virtualization perspective. To do so, the hypervisor updates the client prefix page with the I/O interrupt information and updates the client instruction address to point to the client I/O interrupt handler before dispatching the client prefix page. This requires access to both the client store and the client state (instruction address). To provide this and similar functionality, hypervisors typically have unlimited access to client machine (VM) state and storage in the machine, which, as described herein, may be unsecure and untrusted, and therefore undesirable to the client. However, the hypervisor may be a non-secure entity, and the Virtual Machine (VM) is a secure entity. In one or more examples, the security entity may also include a virtual container or a client. In one or more examples, the non-secure entity can also include an operating system instantiated in a Virtual Machine (VM). In one or more embodiments, host 10 may also be considered an insecure entity. Accordingly, one or more embodiments of the present invention provide for restricting privileges of a hypervisor and also facilitating completion of operations handled by the hypervisor, such as in the case of I/O operations, without authorizing access to a secure client facility.

A Virtual Machine (VM) running as a client under the control of a host hypervisor relies on the hypervisor to transparently provide virtualization services for the client. These services may include, but are not limited to, memory management, instruction emulation, and interrupt handling. The technical solution provided by one or more embodiments of the present invention can be applied to any interface between a secure entity and another untrusted entity that traditionally allows this other entity to access secure resources. For example, for interrupt and exception emulation, the hypervisor typically reads and/or writes the client's prefix region (low core). 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.) that the virtual machine state is maintained by a hypervisor executing on an underlying host (physical processor or a group of processors). From the perspective of a user or software resource, a virtual machine appears to be its own independent physical machine. The terms "hypervisor" and "Virtual Machine Monitor (VMM)" as used herein refer to a processing environment or platform service that manages and permits multiple Virtual Machines (VMs) to execute using multiple (and sometimes different) OSs on the same host. It should be understood that deploying a Virtual Machine (VM) includes an installation process of the Virtual Machine (VM) and an activation (or turn-on) process of the Virtual Machine (VM). In another example, deploying a Virtual Machine (VM) includes an activation (or starting) process of the Virtual Machine (VM) (e.g., where the Virtual Machine (VM) was previously installed or already exists).

In currently available solutions, a hypervisor (e.g.,is/are as followsOr open source software kernel-based virtual machine (KVM)) dispatches a new Virtual Machine (VM) virtual cpu (vcpu) on a physical processing unit or host server by issuing a Start Interpretive Execution (SIE) instruction that causes the SIE entry millicode to be invoked. The operands of the SIE instruction are control blocks containing the client state, called State Descriptions (SD). In prior implementations, the state description resides in the hypervisor store. This guest state, including general purpose and control registers, guest instruction addresses, and guest Program Status Words (PSW), is loaded into hardware by millicode during SIE entry. This allows the guest vCPU to run on the physical processor. When the vCPU runs on hardware, the guest state is maintained in hardware. At some point, the hardware/millicode must return control to the hypervisor. This is commonly referred to as a SIE exit. This may be necessary, for example, if the vCPU executes instructions that need to be emulated by the hypervisor or if a vCPU time slice (i.e., the time allocated for the vCPU to run on a physical processor) expires. During the SIE exit, millicode preserves the current guest state in the state description since the hardware has resources to support only a single vCPU at any given time and the hypervisor state must now be loaded into the hardware. Although the vCPU is not scheduled, its state remains in the state description. Because the state description is located within the hypervisor store, in such cases the hypervisor has control over the data of the Virtual Machine (VM), and in some cases such control is needed to emulate the instructions executing on the Virtual Machine (VM). Existing hypervisors rely on dispatching vcpus through SIE instructions using such interfaces.

However, to facilitate a secure client, there are technical challenges in which a computer server (e.g., a managed node) must provide increased security between the hypervisor and the secure client, such that the hypervisor cannot access data from the Virtual Machines (VMs), and thus cannot provide services in the manner described above.

Some instructions, such as input/output (I/O) operations, are delegated to the hypervisor. Thus, the hypervisor must perform an interpretation of those instructions, which in many cases may cause a guest exception (program interrupt), such as when specifying invalid parameters or operands. This results in a situation where only the hypervisor knows which parameters or operands are valid, and cannot present an exception (program interrupt) directly to the secure client, i.e., the secure Virtual Machine (VM), thus providing a new interface that allows the hypervisor to control the injection of interrupts into the client over the secure interface. Furthermore, in some cases where the hypervisor monitors external or I/O interrupts on behalf of a secure Virtual Machine (VM), it must also be able to present external or I/O interrupts to the Virtual Machine (VM).

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

In one example, the secure interface control is implemented in internal, secure, and trusted hardware and/or firmware. For secure clients or entities, the secure interface controls provide initialization and maintenance of the secure environment and coordination of the dispatch of these secure entities on the hardware. When a secure client is actively using data and it resides in host storage, it remains "clean" in secure storage. The secure client storage may be accessed by the single secure client — this is strictly enforced by hardware. That is, the hardware prevents any non-secure entity (including a hypervisor or other non-secure client) or different secure client from accessing the data. In this example, the secure interface controlsManufactured to run as the lowest level, trusted portion of the firmware. The lowest level or millicode is actually an extension of hardware and is used to implement, for example, IBMThe complex instructions and functions defined in (1). 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 customer storage, and shared storage. The terms storage and memory are used interchangeably herein. This allows it to provide any functionality required by the secure guest or hypervisor to support the guest. The secure interface control also has direct access to the hardware, which allows the hardware to effectively provide security checks under the control of the conditions established by the secure interface control.

One or more embodiments of the present invention address such technical challenges by providing a new interface that allows the interrupt to be injected into a Virtual Machine (VM) by hardware or firmware. Further, one or more embodiments of the invention provide such increased security while still allowing the hypervisor to provide services to the Virtual Machines (VMs). This is accomplished by incorporating into the new "secure interface control" the functionality or portion of the functionality that accesses the secure client facility and is typically done by the hypervisor on behalf of the client. The injection method used by one or more embodiments of the present invention may be applied to any interrupt type that a hypervisor may need to inject. In one or more examples, such functionality may be provided through the use of microcode and/or other hardware modules, and collectively referred to herein as being controlled by a secure interface. Millicode is trusted firmware that acts as an extension of the processor hardware. Thus, one or more embodiments of the invention facilitate a hypervisor to securely and securely inject interrupts into a secure client, and to communicate through secure interface controls that an interrupt condition has occurred that must be handled by that client.

Following now a brief description of the background art, following which certain features used by one or more embodiments of the present invention for injecting interrupts and/or exceptions by a hypervisor into a secure Virtual Machine (VM) are described. It is to be understood in advance that although the present disclosure includes detailed descriptions with respect to cloud computing, implementation of the teachings referenced herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in connection with any other type of computing environment now known or later developed.

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

The characteristics are as follows:

self-service as required: the cloud customer can unilaterally provision computing capabilities, such as server time and network storage, automatically as needed without human interaction with the service provider.

Broad network access: capabilities are available over a network and accessed through standard mechanisms that facilitate use by heterogeneous, thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pool: the provider's computing resources are pooled to serve multiple customers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence in that customers typically have no control or knowledge of the exact location of the provided resources, but may be able to specify locations at higher levels of abstraction (e.g., country, state, or data center).

Quick elasticity: the ability to zoom out quickly and elastically (in some cases, automatically) and to release quickly to zoom in quickly may be provided quickly and flexibly. For the customer, the capabilities available for provisioning typically appear unlimited and may be purchased in any number at any time.

Service of measurement: cloud systems automatically control and optimize resource usage by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and the customer of the utilized service.

The business model is as follows:

software as a service (SaaS): the capabilities provided to the customer are using the provider's applications running on the cloud infrastructure. Applications may be accessed from different client devices through a thin client interface, such as a web browser (e.g., web-based email). Customers do not manage or control the underlying cloud infrastructure including network, server, operating system, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

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

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

The deployment model is as follows:

private cloud: the cloud infrastructure operates only for organizations. It may be managed by an organization or a third party and may exist either on-site or off-site.

Community cloud: the cloud infrastructure is shared by several organizations and supports specific communities with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It may be managed by an organization or a third party and may exist either on-site or off-site.

Public cloud: the cloud infrastructure is made available to the public or large industry groups and owned by the organization that sells the cloud services.

Mixing cloud: a cloud infrastructure is a composition of two or more clouds (private, community, or public) that hold unique entities but are bound together by standardized or proprietary techniques that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

Cloud computing environments are service-oriented, focusing on state, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes.

Referring now to FIG. 1, an illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud customers, such as Personal Digital Assistants (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, and/or automobile computer systems 54N, may communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or a combination thereof. This allows the cloud computing environment 50 to provide infrastructure, platforms, and/or software as a service for cloud customers without maintaining resources on the local computing devices. It should be understood that the types of computing devices 54A-N shown in fig. 1 are intended to be illustrative only, and that computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now to FIG. 2, a set of functional abstraction layers provided by cloud computing environment 50 (FIG. 1) is shown. It should be understood in advance that the components, layers, and functions shown in fig. 2 are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

the hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host computer 61; a RISC (reduced instruction set computer) architecture based server 62; a server 63; a blade server 64; a storage device 65; and a network and networking component 66. In some embodiments, the software components include web application server software 67 and database software 68.

The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: the virtual machine 71; a virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual client 75.

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

Workload layer 90 provides an example of the functionality that may utilize a cloud computing environment. Examples of workloads and functions that may be provided from this layer include: map and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; a transaction 95; and source code versioning 96. It should be understood that these are just some examples, and in other embodiments, layers may include different services.

FIG. 3 illustrates an example hosting node 10 according to one or more embodiments of the invention. The hosting node 10 communicates directly or indirectly with one or more client devices 20A-20C via a network 165. The hosting node 10 may be a data center or a host server of a cloud computing provider. The managed node 10 executes a hypervisor 12 that facilitates the deployment of one or more virtual machines 15 (15A-15N). The managed node 10 also includes a hardware layer 13, the hardware layer 13 including one or more hardware modules and millicode that facilitates the hypervisor 12 providing one or more services to the virtual machine 15 (including the secure interface control 11). In the prior art solution, there is communication between the hypervisor 12 and the hardware/microcode 13; hardware/microcode 13 and one or more Virtual Machines (VMs) 15; a hypervisor 12 and one or more Virtual Machines (VMs) 15; and the hypervisor 12 to the Virtual Machine (VM)15 through the hardware/millicode 13. To facilitate a secure Virtual Machine (VM) environment, a 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 Virtual Machines (VMs) 15, but rather provides communication through the secure interface control 11.

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

In an example, 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 hosting node 10 may operate as a private cloud of entities. In this case, the hosting node 10 hosts only the virtual machines 15A-15N deployed by the client devices 20A-20C belonging to the entity. In another example, client devices 20A-20C may belong to different entities. For example, a first entity may own client device 20A, while a second entity may own client device 20B. In this case, the hosting node 10 may operate to host virtual from different entities A public cloud of machines. For example, virtual machines 15A-15N may be deployed in a shrouded manner where virtual machine 15A does not have convenient access to virtual machine 15B. For example, the hosting node 10 may use IBM zProcessor resource/system manager (PR/SM) Logical Partition (LPAR) features to overlay virtual machines 15A-15N. These features (such as PR/SM LPAR) provide isolation between partitions, thus facilitating managed node 10 deploying two or more virtual machines 15A-15N in different logical partitions for different entities on the same physical managed node 10.

The client device 20A from the client devices 20A-20C is a communication device, such as a computer, smartphone, tablet, desktop computer, laptop computer, server computer, or any other communication device requesting deployment of a virtual machine by the hypervisor 12 of the hosting node 10. Client device 20A may send the request received by the hypervisor via network 165 or directly. Virtual machine 15A from virtual machines 15A-15N is a virtual machine image that is deployed by hypervisor 12 in response to requests from client devices 20A-20C from client devices 20A. Hypervisor 12 is a Virtual Machine Monitor (VMM) which may be software, firmware, or hardware that creates and runs virtual machines. Hypervisor 12 facilitates virtual machine 15A to execute programs and/or store data using hardware components of managed node 10. With appropriate features and modifications, hypervisor 12 can be IBM z ORACLE VM SERVERTM, CITRIX XENSERVER, VMWARE ESXTM, MICROSOFT HYPER-VTM, KVM, or any other hypervisor. Hypervisor 12 may be a native hypervisor executing directly on managed node 10, or a managed hypervisor executing on another hypervisor.

FIG. 4 illustrates components of an example hosting node in accordance with one or more embodiments of the invention. The managed node 10 may be a computer, such as a server computer, desktop computer, tablet computer, smartphone, or any other computer executing a hypervisor 12, the hypervisor 12 in turn deploying virtual machines 15A-15N. The managed node 10 includes components, including hardware, such as electronic circuitry. Hosting node 10 includes, among other things, a processor 105, a memory 110 coupled to a memory controller 115, and one or more input devices 145 and/or output devices 140, such as peripheral or control devices communicatively coupled via a local I/O controller 135. These devices 140 and 145 may include, for example, battery sensors, location sensors (altimeter 40, accelerometer 42, GPS44), indicators/identification lights, and the like. Input devices such as a conventional keyboard 150 and mouse 155 may be coupled to the I/O controller 135. The I/O controller 135 may be, for example, one or more buses or other wired or wireless connections, as is known in the art. The I/O controller 135 may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, omitted for simplicity to enable communications.

The I/O devices 140, 145 may further include devices that communicate both input and output, such as disk and tape storage, Network Interface Cards (NICs) or modulators/demodulators (for accessing other files, devices, systems, or networks), Radio Frequency (RF) or other transceivers, telephony interfaces, bridges, routers, and so forth.

The processor 105 is a hardware device for executing hardware instructions or software, particularly those stored in the memory 110. The processor 105 may be a custom made or commercially available processor, a Central Processing Unit (CPU), an auxiliary processor among several processors associated with the managed node 10, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or other device for executing instructions. Processor 105 includes a cache 170, which may include, but is not limited to, an instruction cache to accelerate executable instruction fetching, a data cache to accelerate data fetching and storing, and a Translation Lookaside Buffer (TLB) to accelerate virtual-to-physical address translations of executable instructions and data. The cache 170 may be organized into a hierarchy of more cache levels (L1, L2, etc.).

The memory 110 may include one or a combination of volatile memory elements (e.g., random access memory, RAM, such as DRAM, SRAM, SDRAM) and non-volatile memory elements (e.g., flash memory, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), tape, compact disc read-only memory (CD-ROM), disk, floppy disk, cartridge, cassette, or the like). In addition, the memory 110 may incorporate electronic, magnetic, optical, or other types of storage media. Note that the memory 110 may have a distributed architecture, where different components are located remotely from each other, but may be accessed by the processor 105.

The instructions in memory 110 may comprise one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 2, the instructions in memory 110 comprise a suitable Operating System (OS) that executes hypervisor 12. The operating system may control the execution of other computer programs and provide scheduling, input-output control, file and data management, memory management, and communication control and related services. In an example such as z System TM, the manufacturer of the managed node 10 may provide the hypervisor 12. In the case of a system having a different architecture than the z-system, where the hypervisor 12 is not provided by the hardware manufacturer, the cloud computing provided may use the hypervisor 12, for example from a VMWARETM, KVM, or other hypervisor provider. In an example, an administrator of the physical hosting node 10 cannot modify the hypervisor 12 unless needed in order to apply the services provided by the manufacturer. For example, hypervisor 12 may be provided as part of the "Licensed Internal Code (LIC)" and/or microcode of managed node 10.

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

The hosting node 10 may further include a display controller 125 coupled to a user interface or display 130. In some embodiments, display 130 may be an LCD screen. In other embodiments, display 130 may include a plurality of LED status lights. In some embodiments, the hosting node 10 may further comprise a network interface 160 for coupling to a network 165. Network 165 may be an IP-based network for communicating between the hosting node 10 and external servers, clients, etc. via a broadband connection. In an embodiment, the network 165 may be a satellite network. The network 165 transmits and receives data between the hosting node 10 and external systems. In some embodiments, network 165 may be a managed IP network managed by a service provider. The network 165 may be implemented wirelessly, for example, using wireless protocols and technologies such as WiFi, WiMax, satellite, or any other protocol. The network 165 may also be a packet-switched network, such as a local area network, a wide area network, a metropolitan area network, the internet, or other similar type of network environment. Network 165 may be a fixed wireless network, a wireless Local Area Network (LAN), a wireless Wide Area Network (WAN), a Personal Area Network (PAN), a Virtual Private Network (VPN), an intranet, or other suitable network system, and may include devices for receiving and transmitting signals.

Client device 20A may request hypervisor 12 to deploy a corresponding virtual machine 15A having access to particular hardware and/or software components of managed node 10. For example, the client device 20A may request that the virtual machine 15A have access to a predetermined number of processors, a predetermined amount of volatile memory (e.g., Random Access Memory (RAM)), a predetermined amount of non-volatile memory (e.g., storage space), or any other hardware component. Alternatively or additionally, client device 20A may request that virtual machine 15A may access a particular hardware component, such as an electronic circuit identified by a corresponding unique identifier. For example, client device 20A may request that virtual machine 15A have access to a particular type of processor, co-processor, network card, or any other chip or electronic circuit. In an example, the client device 20A may identify the electronic circuit using an identifier provided by the manufacturer of the electronic circuit. In an example, the identifier may be used in conjunction with a version identifier. Alternatively or additionally, client device 20A may request that virtual machine 15A may access a particular software component, such as an operating system, an application program, a basic input/output system (BIOS), a boot image, or any other software component. The requested software components may include firmware and embedded programs in the hardware components of the managed node 10. Client device 20A may identify the requested software component using a respective unique identifier provided by the developer/manufacturer of the respective software component. In an example, the identifier may be used in conjunction with a version identifier of the software component.

FIG. 5 sets forth a flow chart illustrating an exemplary method for a hypervisor to provide notification of an interrupt to a secure Virtual Machine (VM) through a secure interface control according to one or more embodiments of the present invention. The method includes scheduling a secure Virtual Machine (VM)15A vCPU and allocating processors 105 and other computing resources to the secure Virtual Machine (VM)15A by executing SIE (start interpreting execution) instructions. The SIE instruction places the processor 105 in an emulation state defined in a control block in memory 110, which is commonly referred to as a State Descriptor (SD). Typically, the SIE instruction has one operand that addresses the SD. That is, the SD contains fields that define the hardware state to be emulated on the processor(s) 105 as may be requested by the client device 20 for the secure Virtual Machine (VM) 15A. In one or more examples, processor 105 may be considered a virtual processor in that processor 105 may be instructed to emulate the behavior of another processor architecture at the request of client 20 that initiated secure Virtual Machine (VM) 15A.

According to one or more embodiments of the invention, the SD field includes: (1) a source field containing an absolute memory address at which the real address zero of the secure Virtual Machine (VM) (i.e., the client) is allocated, which locates the zero page of the client, (2) a field of the current PSW (program state word) of the secure Virtual Machine (VM)15A, (3) a region holding the general purpose register (GR) and Control Register (CR) of the secure Virtual Machine (VM)15A, and (4) miscellaneous other fields for other guest states.

The method includes, at 505, the host 10 determining that an interrupt should be injected and creating the interrupt so that the interrupt can be injected into a secure Virtual Machine (VM) 15A. The interrupt may be an I/O, an external interrupt, or any other type of interrupt. As previously described, the hypervisor 12 cannot directly access memory, registers, or any other data of the secure Virtual Machine (VM)15A, preventing the hypervisor 12 from injecting interrupts directly into the secure Virtual Machine (VM)15A, by saving the guest interrupt information directly into the Virtual Machine (VM) prefix page and loading the interrupt new PSW into the current Virtual Machine (VM) state, as can be done in prior art solutions, i.e., SD, prior to rescheduling.

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

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

If the verification of the interrupt type and the parameter type is successful, the secure interface control 11 injects an interrupt into the secure Virtual Machine (VM)15A and execution of the secure Virtual Machine (VM)15A resumes at 530 and 535. The secure interface control 11 injects the interrupt by adding information of the interrupt and corresponding parameters to the memory (prefix page) and registers of the secure Virtual Machine (VM) 15A. Further, at 535, secure Virtual Machine (VM)15A execution resumes as the interrupt is raised.

At 540, in the event that incorrect values and/or parameters of the interrupt are verified by secure interface control 11, secure interface control 11 indicates an error, e.g., via a validity intercept to hypervisor 12, and does not resume execution of secure Virtual Machine (VM) 15A. Upon receiving the validity intercept, security interface control 11 or hypervisor 12 may issue an alert indicating a possible security breach as described herein.

Thus, the above-described method facilitates hypervisor 12 injecting interrupts into secure Virtual Machine (VM)15A when hypervisor 12 does not have direct access to the memory/register space associated with secure Virtual Machine (VM) 15A.

Further, one or more embodiments of the invention facilitate the secure Virtual Machine (VM)15A causing an interrupt or program exception to be raised in the hypervisor 12.

Technical challenges exist when the secure Virtual Machine (VM)15A executes program instructions, for example, as part of operations performed by an application executing in the secure Virtual Machine (VM)15A, and if the program instructions require interception of the hypervisor 12. The hypervisor 12, as part of the emulation of that customer service program instruction, determines that there is a client exception associated with the program instruction, but does not have access to any registers/memory associated with the secure Virtual Machine (VM)15A that are necessary to present the exception to the Virtual Machine (VM). One or more embodiments of the invention described herein facilitate injecting exceptions into a Virtual Machine (VM) 15A.

FIG. 6 sets forth a flow chart illustrating an exemplary method for a hypervisor to cause an exception in a secure Virtual Machine (VM) in response to emulation of a client instruction according to one or more embodiments of the present invention. The method includes the secure Virtual Machine (VM)15A issuing an instruction requiring hypervisor intervention at 605. For example, the instruction may be a request for an I/O channel of host 10, an instruction to enable asynchronous interrupts, or any other such instruction that requires services of hypervisor 12.

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

At 620, hypervisor 12 determines whether an exception was encountered during the emulation of the instruction. If no exception is encountered, then at 625 the hypervisor 12 resumes execution of the secure Virtual Machine (VM) 15A. At 630, the secure Virtual Machine (VM)15A accordingly resumes operation using guest state according to the state descriptor associated with the secure Virtual Machine (VM) 15A.

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

During SIE entry, secure interface control 11 examines the state descriptor of secure Virtual Machine (VM)15A and identifies exception information added by hypervisor 12. At 645, secure interface control 11 determines whether to pass the exception to secure Virtual Machine (VM) 15A. The secure interface control 11 makes the determination based on the exception list allowed to be passed to the secure Virtual Machine (VM) 15A. The exception list may be specific to the secure Virtual Machine (VM)15A, and may be a predetermined list or a list provided by the client that initiated the secure Virtual Machine (VM)15A, or the like.

Further, in one or more examples, secure interface control 11 checks whether the exception passed to secure Virtual Machine (VM)15A is appropriate based on the instruction passed to hypervisor 12 for execution. For example, secure interface control 11 may have a list of guest instructions that may be intercepted to hypervisor 12, and for each instruction, a set of one or more exceptions that may be passed back to secure Virtual Machine (VM)15A by hypervisor 12. If the exception being passed is not from the exception set corresponding to the instruction being executed in secure Virtual Machine (VM)15A, secure interface control 11 indicates an error at 650 by, for example, intercepting the validity by raising an alarm as described herein.

Further, at 645, the secure interface control 11 determines the appropriateness of the exception passed to the secure Virtual Machine (VM)15A by examining the parameter passed by the exception. If the parameter does not match one or more of the allowed parameter types, then at 650, secure interface control 11 issues an error condition or alarm.

Conversely, if the exception and parameters passed by the hypervisor 12 to the secure Virtual Machine (VM)15A are valid, the secure interface control 11 injects the exception into the secure Virtual Machine (VM)15A at 655. Injecting the exception into the secure Virtual Machine (VM)15A includes: for example, one or more register values and memory (low core) values of the secure Virtual Machine (VM)15A that indicate to the operating system of the Virtual Machine (VM)15A that an exception has occurred are changed. At 630, secure Virtual Machine (VM) execution is further resumed. Recovery includes the secure Virtual Machine (VM)15A handling exceptions caused by the instructions being executed before being intercepted.

Accordingly, one or more embodiments of the invention facilitate injection of exceptions by hypervisor 12 into secure Virtual Machine (VM) 15A.

In accordance with one or more embodiments of the invention, a computer server may host a secure Virtual Machine (VM) that prohibits a hypervisor from accessing memory, registers, and other data associated with the secure Virtual Machine (VM) without having to change the hypervisor and/or secure Virtual Machine (VM) code/architecture to inject interrupts into the hypervisor and/or to inject exceptions into the secure Virtual Machine (VM). Instead, in accordance with one or more embodiments of the present invention, a secure interface control including millicode facilitates such injection using a state descriptor and a secure portion of memory/memory to communicate interrupt/exception information. Further, the secure interface controls performing a validity check on the interrupt/exception information to prevent malicious information from passing between the secure Virtual Machine (VM) and the hypervisor, and in this way continues to maintain the security of the secure Virtual Machine (VM).

One or more embodiments of the invention are rooted in computer technology, particularly virtual machines hosting computer servers. Further, one or more embodiments of the present invention facilitate improvements in the operation of the computing technology itself (particularly virtual machines hosting computer servers) by facilitating the hosting of secure Virtual Machines (VMs) by the hosting computer servers, even if the hypervisor is prohibited from accessing memory, registers, and other such data associated with the secure Virtual Machines (VMs). Furthermore, one or more embodiments of the present invention provide an important step towards improving Virtual Machine (VM) hosting compute servers by facilitating the separation of secure Virtual Machines (VMs) from hypervisors through the use of hardware layers and/or secure interface controls that include millicode, and thus maintaining the security of the Virtual Machines (VMs) hosted by the compute servers. The hardware layer provides lightweight intermediate operations to facilitate security without adding significant overhead to inject interrupts and/or exceptions as described herein.

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

The computer readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device (such as punch cards) or a raised structure in a recess having instructions recorded thereon), and any suitable combination of the foregoing. A computer-readable storage medium as used herein should not be interpreted as a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or an electrical signal transmitted through a wire.

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

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including an object oriented Smalltalk, C + + or the like programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), may personalize the electronic circuit by executing computer-readable program instructions with state information of the computer-readable program instructions in order to perform various aspects of the present invention.

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

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein comprise an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

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

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative embodiments, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The description of the different embodiments of the invention has been presented for purposes of illustration but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application, or technical improvements to the technology found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims (25)

1. A computer-implemented method, comprising:

initiating, by a non-secure entity executing on a host server, a secure entity, prohibiting the non-secure entity from directly accessing any data of the secure entity; and is

Injecting an interrupt generated by the host server or by the non-secure entity into the secure entity, the injecting comprising:

adding, by the non-secure entity, information about the interruption into a portion of non-secure storage associated with the secure entity; and is

Injecting the interrupt into the secure entity is controlled by a secure interface of the host server.

2. The computer-implemented method of claim 1, wherein the non-secure entity is a hypervisor and the secure entity is a secure virtual machine.

3. The computer-implemented method of claim 1 or 2, wherein the secure entity is a container and the non-secure entity is an operating system.

4. The computer-implemented method of one of claims 1 to 3, further comprising:

prior to the injecting, determining, by the secure interface control, whether to allow the interrupt to be injected into the secure entity, wherein the injecting is performed based on determining that the interrupt is allowed to be injected into the secure entity.

5. The computer-implemented method of claim 4, wherein the secure interface control determines that the interrupt is allowed to be injected into the secure entity based on a predetermined list of allowable interrupts for the secure entity.

6. The computer-implemented method of claim 5, wherein the list of allowable interrupts is specific to the security entity.

7. The computer-implemented method of claim 4, the method further comprising indicating, by the secure interface control, an error to the non-secure entity in response to determining that the interrupt is not permitted to be injected into the secure entity.

8. The computer-implemented method of one of claims 1 to 7, further comprising: deallocating a virtual processor associated with the secure entity prior to injection by the non-secure entity.

9. The computer-implemented method of one of claims 1 to 8, further comprising: prior to the injection, determining, by the secure interface control, whether to allow injection of the interrupt and one or more parameters into the secure entity, wherein the injection is performed based on determining that the interrupt and the one or more parameters are allowed to be injected into the secure entity.

10. The computer-implemented method of one of claims 1 to 9, wherein adding the information about the interrupt comprises one of:

storing, by the non-secure entity, the information about the interrupt into a state descriptor associated with the secure entity; and is

Issuing, by the non-secure entity, an instruction to cause the secure control interface to store the information about the interrupt into a state descriptor associated with the secure entity.

11. A system, comprising:

a memory;

controlling a safety interface; and

a processing unit coupled with the memory and the secure interface control, the processing unit configured to execute a non-secure entity hosting one or more secure entities, the non-secure entity being prohibited from directly accessing any data of a secure entity, and wherein the method for injecting an interrupt generated by the non-secure entity into the secure entity comprises:

adding, by the non-secure entity, information about the interruption into a portion of non-secure storage associated with the secure entity; and is

Controlling, by the secure interface, injection of the interrupt into the secure entity.

12. The system of claim 11, wherein the method further comprises:

deallocating a processor associated with the secure entity prior to injection by the non-secure entity.

13. The system of claim 12, wherein after the information about the interrupt is added by the non-secure entity, the virtual processor is reallocated to resume operation of the secure entity.

14. A computer program product comprising a computer-readable storage medium including computer-executable instructions that, when executed by a processing unit, cause the processing unit to perform a method, the method comprising:

initiating, by a non-secure entity executing on a host server, a secure entity, prohibiting the non-secure entity from directly accessing any data of the secure entity; and is

Injecting, by the non-secure entity, an interrupt generated by the host server into the secure entity, the injecting comprising:

adding, by the non-secure entity, information about the interruption into a portion of non-secure storage associated with the secure entity;

Restoring, by the non-secure entity, a processor associated with the secure entity to restore operation of the secure entity; and is

The injection of the interrupt into the secure entity is controlled by a secure interface.

15. The computer program product of claim 14, wherein the method further comprises:

deallocating a processor associated with the secure entity prior to injection by the non-secure entity.

16. The computer program product of claim 15, wherein the secure interface control determines that the interrupt is allowed to be injected into the secure entity based on a predetermined list of allowable interrupts for the secure entity.

17. The computer program product of claim 15 or 16, wherein the method further comprises:

reassigning a virtual processor to resume operation of the secure entity after the information about the interrupt is added by the non-secure entity.

18. The computer program product of one of claims 14 to 17, wherein the information about the interrupt comprises an identifier of the interrupt to be injected and one or more parameters associated with the interrupt.

19. A computer-implemented method, comprising:

instructions executed by a secure entity executing on a non-secure entity on a host server, the instructions generating a program exception to be forwarded to the non-secure entity and generating a program exception, the non-secure entity being prohibited from directly accessing any data of the secure entity; and is

Presenting, by a secure interface control, the instruction to the non-secure entity;

executing, by the non-secure entity, the instruction; and

injecting the program exception from the non-secure entity into the secure entity, the injecting comprising:

based on the program exception raised by the emulation of the instruction, adding, by the non-secure entity, information about the program exception into a portion of non-secure storage associated with the secure entity; and is

Restoring, by the non-secure entity, a processor associated with the secure entity to restore operation of the secure entity.

20. The computer-implemented method of claim 19, further comprising:

deallocating a processor associated with the secure entity prior to presentation of the instruction to the non-secure entity by the secure interface control.

21. The computer-implemented method of claim 20, after the information about the program exception is added by the non-secure entity, reallocating virtual processors to resume operation of the secure entity.

22. The computer-implemented method of claim 19 or 20, wherein the information about the program exception comprises an identifier of the program exception to be injected and one or more parameters associated with the program exception.

23. A system, comprising:

a memory;

controlling a safety interface; and

a processing unit coupled with the memory and the secure interface control, the processing unit configured to execute a non-secure entity hosting a plurality of secure entities, the non-secure entity being prohibited from directly accessing any data of a secure entity, and wherein the system is configured to perform a method to inject a program exception from the non-secure entity into the secure entity, the method comprising:

presenting, by a secure interface control, an instruction to the non-secure entity;

executing, by the non-secure entity, the instruction; and

injecting the program exception from the non-secure entity into the secure entity, the injecting comprising:

Based on the program exception raised by the emulation of the instruction, adding, by the non-secure entity, information about the program exception into a portion of non-secure storage associated with the secure entity; and is

Restoring, by the non-secure entity, a processor associated with the secure entity to restore operation of the secure entity.

24. The system of claim 23, wherein the method further comprises: deallocating a processor associated with the secure entity prior to presentation of the instruction to the non-secure entity by the secure interface control.

25. The system of claim 23 or 24, wherein the method further comprises: reassigning a virtual processor to resume operation of the secure entity after the information about the program exception is added by the non-secure entity.