Communication interface of the safety interface control

Abstract

A method is provided. The method is implemented by a communication interface of a security interface control executed between the security interface control of a computer and hardware of the computer, in which the communication interface receives an instruction and determines whether the instruction is a millicoded instruction. In addition, the communication interface enters millicode, including enabling the security interface control to engage the millicode of the hardware through the communication interface based on the instruction being a millicoded instruction. The millicode then executes the instruction.

Description

Background Art

[0001] The present invention generally relates to computer technology, and more particularly to a communication interface for a secure interface control.

[0002] Cloud computing and cloud 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 supply virtual machines (VMs) to customers without the need for customers to purchase hardware or provide floor space for physical servers. Customers can easily expand or shrink VMs according to the changing preferences or requirements of customers. Typically, cloud computing providers supply VMs that physically reside on servers at the provider's data center. Customers are often concerned about the security of data in VMs, especially because computing providers typically store data for more than one customer on the same server. Customers may expect security between their own code / data and the code / data of cloud computing providers, as well as security between their own code / data and the code / data of other VMs running at the provider's location. In addition, customers may expect security from the provider's administrators, as well as protection against potential security breaches from other codes running on the machine.

[0003] To handle such sensitive situations, cloud service providers can implement security controls to ensure proper data isolation and logical storage separation. The widespread use of virtualization in implementing cloud infrastructures leads to unique security issues for customers of cloud services because virtualization changes the relationship between the operating system (OS) and the underlying hardware (whether it is computing, storage, or even networking hardware). This introduces virtualization as an additional layer that itself must be properly configured, managed, and secured.

[0004] Typically, a VM running as a guest under the control of a host hypervisor relies on the hypervisor to transparently provide virtualization services to the guest, including memory management, instruction emulation, and interrupt handling. Summary of the invention

[0005] According to one or more embodiments, a method is provided. The method is implemented by a communication interface of a security interface control executed between a security interface control of a computer and the hardware of the computer, in which the communication interface receives an instruction and determines whether the instruction is a millicoded instruction. In addition, the communication interface enters the millicode, including enabling the security interface control to engage the millicode of the hardware through the communication interface based on the instruction being a millicoded instruction. Then, the millicode executes the instruction. The technical effects and benefits of one or more embodiments include eliminating the need for context switching and associated processing overhead.

[0006] According to one or more embodiments or the above method embodiments, the instructions may be executed by hardware of a computer based on the fact that the instructions are not millicoded instructions.

[0007] According to one or more embodiments or any of the above method embodiments, the communication interface can exit the millicode after the instruction is executed by the millicode. Therefore, the technical effects and benefits of the embodiments herein include that the communication interface does not include any software context switching or any overhead associated with such context switching.

[0008] According to one or more embodiments or any method embodiment of the above method embodiments, the security interface control may communicate with a non-secure entity or a secure entity that issues instructions.

[0009] According to one or more embodiments or any of the above method embodiments, the non-secure entity may include a hypervisor, the secure entity may include a secure client, and the instructions may include architected instructions.

[0010] According to one or more embodiments or any of the above method embodiments, millicode may utilize enhancements to a communication interface to access secure storage associated with instructions in a secure execution context.

[0011] According to one or more embodiments or any of the above method embodiments, the millicode may be an extension of hardware that performs the functionality of the security interface control when executing instructions.

[0012] According to one or more embodiments or any of the above method embodiments, millicode acting as a secure interface control may dispatch a secure entity and set an indication that the secure entity is running and load a secure client state into hardware.

[0013] According to one or more embodiments or any of the above method embodiments, hardware may use a secure client state to perform security checks while a secure client domain associated with a secure entity is running.

[0014] According to one or more embodiments, any one of the above method embodiments may be implemented as a computer program product or a system.

[0015] Additional features and advantages are achieved through the technology of the present invention. Other embodiments and aspects of the present invention are described in detail herein and are considered to be a part of the present invention. In order to better understand the advantages and features of the present invention, please refer to the specification and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] Figure 1 A table illustrating zone security according to one or more embodiments of the present invention;

[0018] Figure 2 shows a virtual address space and an absolute address space for executing a DAT according to one or more embodiments of the present invention;

[0019] Figure 3 A nested, multi-part DAT for supporting virtual machines (VMs) running under a hypervisor is shown in accordance with one or more embodiments of the present invention;

[0020] Figure 4 A mapping of secure client storage according to one or more embodiments of the present invention is shown;

[0021] Figure 5 A system diagram illustrating a dynamic address translation (DAT) operation according to one or more embodiments of the present invention;

[0022] Figure 6 A system schematic diagram of a secure interface control memory according to one or more embodiments of the present invention is shown;

[0023] Figure 7 shows a processing flow of an import operation according to one or more embodiments of the present invention;

[0024] Figure 8 shows a processing flow of an import operation according to one or more embodiments of the present invention;

[0025] Fig. 9 A process of donated memory operation according to one or more embodiments of the present invention is shown;

[0026] Fig.10 A process flow for converting a non-secure hypervisor page to a secure page of a secure interface control according to one or more embodiments of the present invention is shown;

[0027] Fig.11 A process flow of secure storage access by a secure interface control according to one or more embodiments of the present invention is shown;

[0028] Fig.12 The process flow of access marking by a security interface control and by hardware according to one or more embodiments of the present invention is shown;

[0029] Fig.13 A process flow is shown in which conversion between secure and non-secure access is supported by a program and a security interface control according to one or more embodiments of the present invention;

[0030] Fig.14 shows a process flow of a DAT with secure storage protection through a program and a secure interface according to one or more embodiments of the present invention;

[0031] Fig.15 A system including a secure interface control according to one or more embodiments of the present invention is shown;

[0032] Fig.16 The present invention shows one or more embodiments of the present invention. Fig.15 The processing flow of the communication interface of the security interface control;

[0033] Fig.17 A cloud computing environment according to one or more embodiments of the present invention is shown;

[0034] Fig.18 An abstract model layer according to one or more embodiments of the present invention is shown;

[0035] Fig.19 A system according to one or more embodiments of the present invention is shown; and

[0036] Fig. 20 Nodes in accordance with one or more embodiments of the invention are shown.

[0037] The figures described herein are illustrative. Many variations may be made to the figures or operations described therein without departing from the spirit of the present invention. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. In addition, the term "coupled" and variations thereof describe having a communication path between two elements, and do not imply a direct connection between elements without an intermediate element / connection between them. All of these variations are considered part of the specification. DETAILED DESCRIPTION

[0038] According to one or more embodiments, the present invention is directed to providing a communication interface between a security interface control and hardware of the same computer. The communication interface operates to move operations (e.g., instructions) from a software layer to a security interface control provided by the lowest level firmware and hardware, thereby utilizing processing efficiencies provided by the hardware.

[0039] Turning now to an overview of the technology more specifically related to aspects of the present invention, a context switch is a software process that stores the state of a task (e.g., a thread or other process) executing within a machine so that the task can be restored and resumed from the same point at a later time. Context switches enable multiple processes to share a single central processing unit (CPU) and are therefore an essential feature of a multitasking operating system. Context switches naturally have an associated cost processing overhead.

[0040] Turning now to an overview of various aspects of the present invention, one or more embodiments of the present invention solve technical problems by providing an efficient, lightweight communication interface for a security interface control that does not require context switching between software and hardware to provide additional security when running a security domain. In particular, the communication interface utilizes hardware to call security interface control functions. The technical effects and benefits of one or more embodiments include eliminating the need for context switching and associated processing overhead.

[0041] A virtual machine (VM) running as a client under the control of a host hypervisor (e.g., an untrusted entity) relies on the hypervisor to transparently provide virtualization services to the client. These services can be applied to any interface between a secure entity and another untrusted entity that traditionally allows the other entity to access secure resources. As previously mentioned, these services may include, but are not limited to, memory management, instruction emulation, and interrupt handling. For example, for interrupts and exception injection, the hypervisor typically reads and / or writes to the prefix area (low core) of the client. As used herein, the term "virtual machine" or "VM" refers to a logical representation of a physical machine (computing device, processor, etc.) and its processing environment (operating system (OS), software resources, etc.). VM is maintained as software executed on the underlying host (physical processor or processor group). From the perspective of a user or software resource, VM appears to be its own independent physical machine. The terms "hypervisor" and "VM monitor (VMM)" used herein refer to a processing environment or platform service that manages and allows multiple VMs to execute using multiple (sometimes different) OS on the same host. It should be understood that deploying a VM includes: a VM installation process and a VM activation (or startup) process. In another example, deploying the VM includes an activation (or startup) process of the VM (eg, in the case where the VM is previously installed or already exists).

[0042] To facilitate and support secure clients (eg, security entities), technical challenges exist where additional security is required between the hypervisor and the secure client without relying on the hypervisor, such that the hypervisor cannot access data from the VM and therefore cannot provide services in the manner described above.

[0043] The secure execution described herein provides a hardware mechanism to ensure isolation between secure storage devices and non-secure storage devices and between secure storage devices belonging to different secure users. For secure clients, additional security is provided between "untrusted" non-secure hypervisors and secure clients. In order to do this, many functions that the hypervisor usually does on behalf of the client need to be incorporated into the machine. This article describes a new secure interface control (also referred to as "UV" herein) to provide a secure interface between the hypervisor and the secure client. The terms secure interface control and UV are used interchangeably here. The secure interface control works in cooperation with hardware to provide this additional security. In addition, a lower-level hypervisor can provide virtualization for the non-trusted hypervisor, and if the lower-level hypervisor is implemented with trusted code, it can also be a part of the secure interface control.

[0044] In one example, the security interface control is implemented in internal, secure and trusted hardware and / or firmware. For secure clients or entities, the security interface control provides initialization and maintenance of the security environment and coordination of the dispatch of these security entities on the hardware. When the secure client is actively using the data and it resides in the host storage device, it is kept "unhindered" in the secure storage. The secure client storage device can be accessed by this single secure client, which is strictly enforced by the hardware. That is, the hardware prevents any non-secure entity (including the hypervisor or other non-secure client) or different secure clients from accessing the data. In this example, the security interface control runs as a trusted part of the lowest level firmware. The lowest level or millicode is actually an extension of the hardware and is used to implement, for example, The 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 client storage, and shared storage. This allows it to provide any functionality required by a 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 the conditions established by the security interface control.

[0045] According to one or more embodiments of the present invention, software uses UV call (UVC) instructions to request the security interface control to perform a specific action. For example, the UVC instruction can be used by the hypervisor to initialize the security interface control, create a secure client domain (e.g., a secure client configuration), and create a virtual CPU within the secure configuration. It can also be used to import (decrypt and assign to a secure client domain) and export (encrypt and allow host access) secure client pages as part of a hypervisor page-in or page-out operation. In addition, the secure client has the ability to define storage shared with the hypervisor, to make secure storage shared, and to make shared storage secure.

[0046] Now turn to Figure 1 , in accordance with one or more embodiments of the present invention, a table 100 for zone security is generally shown. Figure 1 The regional security table 100 shown is maintained by the security interface control and is used by the security interface control and hardware to ensure secure access to any page accessed by a security entity. The regional security table 100 is indexed by the host absolute address 110. That is, there is an entry for each page of host absolute storage. Each entry includes information for verifying that the entry belongs to the security entity making the access.

[0047] In addition, if Figure 1 As shown, the region security table 100 includes a security domain ID 120 (identifying the security domain associated with the page); a UV bit 130 (indicating that the page is donated to and owned by the security interface control); a disable address comparison (DA) bit 140 (used to disable host address pair comparison in certain circumstances, such as when a security interface control page defined as host absolute does not have an associated host virtual address); a shared (SH) bit 150 (indicating that the page is shared with a non-secure hypervisor) and a host virtual address 160 (indicating the host virtual address registered for the host absolute address, which is referred to as a host-address pair). Note that the host-address pair indicates the host absolute and associated, registered host virtual addresses. The host-address pair represents the mapping of the page, after being imported by the hypervisor, and the comparison ensures that the host does not remap the page while the page is being used by the client.

[0048] Dynamic Address Translation (DAT) is used to map virtual storage to real storage. When a client VM runs as a paging client under the control of a hypervisor, the client uses DAT to manage pages that reside in its memory. Additionally, the host independently uses DAT to manage those client pages (along with its own pages) when the pages reside in its memory. The hypervisor uses DAT to provide isolation and / or sharing of storage between different VMs, as well as to prevent clients from accessing hypervisor storage. When a client runs in non-secure mode, the hypervisor has access to the storage of all clients.

[0049] DAT enables one application to be isolated from another while still allowing them to share common resources. Furthermore, it allows the implementation of a VM that can be used to design and test new versions of the OS and concurrent processing of applications. A virtual address identifies a location in virtual storage. An address space is a contiguous sequence of virtual addresses together with specific transformation parameters (including the DAT table) that allow each virtual address to be converted into an associated absolute address that identifies the address using a byte position in storage.

[0050] DAT uses a multi-table lookup to convert a virtual address into an associated absolute address. This table structure is typically defined and maintained by a storage manager. The storage manager transparently shares absolute storage between multiple programs by paging out a page and, for example, paging in another page. When a page is paged out, the storage manager will, for example, set an invalid bit in the associated page table. When a program attempts to access a page that has been paged out, the hardware will present a program interrupt to the storage manager, commonly referred to as a page fault. In response, the storage manager paging in the requested page and resets the invalid bit. This is all done transparently to the program and allows the storage manager to virtualize storage and share it between a variety of different users.

[0051] When the CPU uses a virtual address to access main memory, it is first converted to a real address by DAT and then to an absolute address by prefixing it. The top level table designation (origin and length) for a particular address space is called an Address Space Control Element (ASCE) and defines the associated address space.

[0052] Now turn to Figure 2 , generally illustrates example virtual address spaces 202 and 204 and an absolute address space 206 for executing a DAT, in accordance with one or more embodiments of the present invention. Figure 2In the example shown, there are two virtual address spaces: virtual address space 202 (defined by address space control element (ASCE) A 208) and virtual address space 204 (defined by ASCE B 210). Virtual pages A1.V 212a1, A2.V 212a2, and A3.V 212a3 are mapped to absolute pages A1.A 220a1, A2.A 220a2, and A3.A 220a3 by the storage manager in a multi-table (segment 230 and page tables 232a, 232b) lookup using ASCE A 208. Similarly, virtual pages B1.V 214b1 and B2.V 214b2 are mapped to absolute pages B1.A 222b1 and B2.A 222b2, respectively, in a dual-table 234 and 236 lookup using ASCE B 210.

[0053] Now turn to Figure 3 , an example of nested multi-part DAT conversion for supporting VMs running under a hypervisor is generally shown in accordance with one or more embodiments of the present invention. Figure 3In the example shown, both the client A virtual address space A 302 (defined by client ASCE (GASCE) A 304) and the client B virtual address space B 306 (defined by GASCEB 308) reside in a shared host (hypervisor) virtual address space 325. As shown, virtual pages A1.GV 310a1, A2.GV 310a2, and A3.GV 310a3 belonging to client A are mapped to client absolute pages A1.HV 340a1, A2.HV 340a2, and A3.HV 340a3, respectively, by the client A storage manager using GASCEA 304; virtual pages B1.GV 320b1 and B2.GV 320b2 belonging to client B are independently mapped to client absolute pages B1.HV 360b1 and B2.HV 360b2, respectively, by the client B storage manager using GASCEB 308. In this example, these client absolute pages are directly mapped into the shared host virtual address space 325, and then undergo additional host DAT conversion to the host absolute address space 330. As shown, host virtual addresses A1.HV 340a1, A3.HV 340a3 and B1.HV 360b1 are mapped to A1.HA 370a1, A3.HA 370a3 and B1.HA 370b1 by the host storage manager using host ASCE (HASCE) 350. Host virtual addresses A2.HV 340a2 belonging to client A and B2.HV 360b2 belonging to client B are all mapped to the same host absolute page AB2.HA 380. This enables data to be shared between the two clients. During client DAT conversion, each of the client table addresses is treated as a client absolute value and undergoes additional nested host DAT conversion.

[0054] Embodiments of the invention described herein provide secure client and UV storage protection. Access to secure storage by non-secure clients and hypervisors is prohibited. The hypervisor specifies that for a given resident secure client page, the following occurs. The associated host absolute address is only accessible through a single hypervisor (host) DAT mapping. That is, there is a single host virtual address that maps to any given host absolute address assigned to a secure client. The hypervisor DAT mapping (host virtual to host absolute) associated with a given secure client page does not change when it is paged in. The host absolute page associated with the secure client page is mapped for a single secure client.

[0055] According to one or more embodiments of the present invention, storage sharing between secure clients is also prohibited. Storage is shared between a single secure client and a hypervisor controlled by the secure client. UV storage is secure storage and is accessible by the secure control interface but not by the client / host. Storage is allocated to the secure control interface by the hypervisor. According to one or more embodiments of the present invention, any attempted violation of these rules is prohibited by the hardware and secure control interface.

[0056] Now turn to Figure 4 , examples of mappings stored by secure clients are generally shown in accordance with one or more embodiments of the present invention. Figure 4 Similar to Figure 3 ,Apart from Figure 4 The example does not allow for sharing storage between secure client A and secure client B. Figure 3 In the non-secure example, host virtual address A2.HV 340a2 belonging to client A and B2.HV 360b2 belonging to client B are both mapped to the same host absolute page AB2.HA 380. Figure 4 In the secure client storage example, host virtual address A2.HV 340a2 belonging to client A is mapped to host absolute address A2.HA 490a, while B2.HV 360b2 belonging to client B is mapped to its own B2.HA 490b. In this example, there is no sharing between secure clients.

[0057] When a secure client page resides on disk, it is encrypted. When a hypervisor page calls in a secure client page, it issues a UV call (UVC), which causes the secure control interface to mark the page as secure (unless shared), decrypt it (unless shared), and register it (in the regional security table) as belonging to the appropriate secure client (e.g., client A). In addition, it registers the associated host virtual address (e.g., A3.HV 340a3) to the host absolute page (referred to as a host address pair). If the hypervisor fails to issue the correct UVC, it receives an exception when it attempts to access a secure client page. When a hypervisor page calls out a client page, a similar UVC is issued that encrypts the client page (unless shared) before marking it as non-secure and registering it as non-secure in the regional security table.

[0058] In the example with five given host absolute pages K, P, L, M, and N, each host absolute page is marked as secure by the security control interface when the hypervisor pages them in. This prevents non-secure clients and hypervisors from accessing them. Host absolute pages K, P, and M are registered as belonging to client A when the hypervisor pages them in; host absolute pages L and N are registered to client B when they are paged in by the hypervisor. Shared pages, i.e., pages shared between a single secure client and hypervisor, are not encrypted or decrypted during paging. They are not marked as secure (allowing hypervisor access), but are registered with a single secure client domain in the region security table.

[0059] According to one or more embodiments of the present invention, when a non-secure client or hypervisor attempts to access a page owned by a secure client, the hypervisor receives a secure storage access (PIC3D) exception. No additional translation steps are required to determine this.

[0060] According to one or more embodiments, when a secure entity attempts to access a page, the hardware performs an additional translation check that verifies that the storage does belong to that particular secure client. If not, a non-secure access (PIC3E) exception is presented to the hypervisor. Additionally, if the host virtual address being translated does not match the host virtual address from the registered host address pair in the zone security table, a secure storage violation ('3F'x) exception is identified. To enable sharing with the hypervisor, a secure client can access storage that is not marked as secure as long as the translation check allows access.

[0061] Now go to Figure 5 , a system diagram 500 of DAT operation is generally shown according to one or more embodiments of the present invention. The system diagram 500 includes a host primary virtual address space 510 and a host home virtual address space 520, from which pages are translated (e.g., see host DAT translation 525; note that the dashed line represents the mapping through DAT translation 525) to a hypervisor (host) absolute address space 530. For example, Figure 5 Shown is sharing of host absolute storage by two different host virtual address spaces, and sharing one of those host virtual addresses not only between two clients but also with the host itself. In this regard, host primary virtual address space 510 and host attribution virtual address space 520 are examples of two host virtual address spaces, each of which is addressed by a separate ASCE (host primary ASCE (HPASCE) 591 and host attribution ASCE (HHASCE) 592) respectively. Note that all security interface control storage (virtual and real) is donated by the hypervisor and is marked as safe. After being donated, the security interface control storage can only be accessed by the security interface control as long as there is an associated security entity.

[0062] As shown, the host primary virtual address space 510 includes client A absolute page A1.HV, client A absolute page A2.HV, client B absolute page B1.HV, and host virtual page H3.HV. The host home virtual address space 520 includes secure interface control virtual page U1.HV, host virtual page H1.HV, and host virtual page H2.HV.

[0063] According to one or more embodiments of the present invention, in the regional security table described herein, all secure client (e.g., secure client A and secure client B) storage is registered as belonging to the secure client configuration, and the associated host virtual address (e.g., A1.HV, A2.HV, B1.HV) is also registered as part of the host address pair. In one or more embodiments, all secure client storage is mapped in the host main virtual space. In addition, all secure interface control storage is also registered in the regional security table as belonging to the secure interface control, and can be further distinguished in the regional security table based on the associated secure client domain. According to one or more embodiments of the present invention, the UV virtual storage device is mapped in the host belonging virtual space, and the associated host virtual address is registered as part of the host address pair. According to one or more embodiments, the UV real storage device does not have an associated host virtual mapping, and the DA bit in the regional security table (which indicates that the virtual address comparison is disabled) is set to indicate this. The host storage device is marked as non-secure and is also registered as non-secure in the regional security table.

[0064] Therefore, in the case of 'guest absolute = host virtual', the hypervisor (host) main DAT table (defined by HPASCE 591) converts the pages of the host main virtual address space 510 as follows: client A absolute page A1.HV is mapped to host absolute A1.HA belonging to secure client A; client A absolute page A2.HV is mapped to host absolute A2.HA belonging to secure client A; client B absolute page B1.HV is mapped to host absolute B1.HA belonging to secure client B; and host virtual page H3.HV is mapped to host absolute page H3.HA non-secure host (and since it is non-secure, there is no host address pair). In addition, the hypervisor (host) home DAT table (defined by HHASCE 592) translates pages of the host home virtual address space 520 as follows: secure interface control virtual page U1.HV is mapped to host absolute page U1.HA defined as secure UV virtual; host virtual page H1.HV is mapped to host absolute page H1.HA defined as non-secure; and host virtual page H2.HV is mapped to host absolute page H2.HA defined as non-secure. There is no host address pair associated with either H1.HA or H2.HA because they are non-secure.

[0065] In operation, if a secure client attempts to access a secure page assigned to a secure interface control, the hardware presents a secure storage violation ('3F'X) exception to the hypervisor. If a non-secure client or hypervisor attempts to access any secure page (including those assigned to the secure interface control), the hardware presents a secure storage access ('3D'X) exception to the hypervisor. Alternatively, an error condition may be presented for an attempted access to the secure interface control space. A check is presented if the hardware detects a mismatch in security assignments in a secure interface control access (e.g., a storage device is registered in the zone security table as belonging to a secure client rather than to a secure interface control, or there is a mismatch between the host address pair used and the registered pair).

[0066] In other words, the host main virtual address space 510 includes host virtual pages A1.HV and A2.HV (belonging to secure client A) and B1.HV (belonging to secure client B), which are mapped to host absolute A1.HA, A2.HA and B1.HA respectively. In addition, the host main virtual address space 510 includes a host (hypervisor) page H3.HV, which is mapped to the host absolute H3.HA. The host attribute virtual space 520 includes two host virtual pages H1.HV and H2.HV, which are mapped to host absolute pages H1.HA and H2.HA. The host main virtual address space 510 and the host attribute virtual address space 520 are both mapped to a single host absolute 530. The storage pages belonging to secure client A and secure client B are marked as secure and are in Figure 1 The zone security table 100 shown is registered with their security domains and associated host virtual addresses. On the other hand, host storage devices are marked as non-secure. When the hypervisor defines secure clients, it must donate host storage to the security interface control for the security control blocks required to support these secure clients. This storage can be defined in host absolute or host virtual space, and in one example, specifically, in the host home virtual space. Return Figure 5 , the host absolute pages U1.HA and U2.HA are secure interface control storage defined as host absolute storage. As a result, these pages are marked as secure and are Figure 1 The region security table 100 shown is registered as belonging to the security interface control and having an associated security domain. Since the page is defined as a host absolute address, there is no associated host virtual address, so the DA bit is set in the region security table 100.

[0067] After conversion, you can Figure 6 An example of the hypervisor (host) absolute address space 530 is found in . Figure 6 A system diagram 600 is depicted regarding a secure interface control memory according to one or more embodiments of the present invention. The system diagram 600 shows a hypervisor (host) absolute address space 630, which includes host absolute page A2.HA secure client A (for A2.HV); host absolute page B1.HA secure client B (for B1.HV); host absolute page H1.HA non-secure (host); host absolute page H2.HA non-secure (host); host absolute page U3.HA secure UV real (no HV mapping); host absolute page U1.HA secure UV virtual (for U1.HV); and host absolute page A1.HA secure client A (for A1.HV).

[0068] Now turn to Figure 7 , in accordance with one or more embodiments of the present invention, a process flow 700 for an import operation is generally shown. When a secure client accesses a page that was paged out by the hypervisor, a sequence of events such as shown in process flow 700 occurs to securely bring the page back. Process flow 700 begins at block 705, where the secure client accesses a client virtual page. Because the page (for example) is invalid, the hardware presents a host page fault indicated by program interrupt code 11 (PIC11) to the hypervisor (see block 715). The hypervisor then identifies an available non-secure host absolute page for the client page (see block 720) and pages the encrypted client page into the identified host absolute page (see block 725).

[0069] At box 730, the host absolute page is then mapped into the appropriate (host virtual address based) host DAT table. Then, at box 735, the hypervisor host re-dispatches the secure client. At box 740, the secure client re-accesses the client secure page. The page fault is no longer present, but since this is a secure client access and the page is not marked as secure in the region security table 100 of FIG. 100, the hardware presents a non-secure storage exception (PIC3E) to the hypervisor at box 745. The PIC3E prevents the client from accessing the secure page until the necessary imports are issued. Next, process flow 700 proceeds to "A", which is connected to Figure 8 .

[0070] Now turn to Figure 8 , a process flow 800 for performing an import operation is generally shown according to one or more embodiments of the present invention. In response to PIC3E, a well-behaved hypervisor (e.g., executing without errors in an expected manner) will issue an import UVC (see box 805). Note that at this point, the page to be imported is marked as non-secure and can only be accessed by the hypervisor, other non-secure entities, and the secure interface control. It cannot be accessed by a secure client.

[0071] As part of importing UVC, the trusted firmware acting as the security interface control checks to see if the page has been locked by the security interface control (see decision block 810). If so, the process flow 800 proceeds to block 820. At block 820, a "busy" return code is returned to the hypervisor, which in response delays (see block 825) and reissues the import UVC (process flow 800 returns to block 805). If the page has not been locked, the process flow 800 proceeds to decision block 822.

[0072] At decision block 822, the security interface control checks to see if the page is a page shared with a non-secure hypervisor. If it is shared (process flow 800 proceeds to decision block 824), the security interface control registers the host absolute address in the region security table with the associated secure client domain, the host virtual address, and as shared. This page remains marked as non-secure. This completes the import UVC, and the page is now available for access by the client. Processing continues, the hypervisor re-dispatches the client (block 830) and the secure client successfully accesses the page (block 835).

[0073] If the host virtual page to be imported is not shared with the hypervisor (process flow 800 proceeds to box 840), the security interface control marks the page as secure so that the hypervisor can no longer access the page. At box 845, the security interface control locks the page so that no other UVC can modify the page state. After setting the lock (at box 850), the security interface control will verify that the contents of the client page have not changed while being encrypted. If they have indeed changed, an error return code is returned to the hypervisor, otherwise, the security interface control will decrypt the secure page.

[0074] At block 855, the security interface control unlocks the page, allowing other UVCs to access, registers the page as secure in the zone security table and associates it with the appropriate guest domain and host virtual address to complete the host address HV->HA pair. This allows the client to access and complete the UVC.

[0075] Now go to Fig. 9 , a process flow 900 is generally shown regarding donated memory operations, in accordance with one or more embodiments of the present invention. Process flow 900 begins at block 905, where the hypervisor issues a query-UVC to the security interface control. At block 910, the security interface control returns data (e.g., the query UVC). The data may include a base region-specific host absolute storage amount required; a base secure guest domain-specific host absolute storage amount required; a variable secure guest domain-specific host virtual storage amount per MB required; and / or a base secure client CPU-specific host absolute storage amount required.

[0076] At block 915, the hypervisor reserves the base host absolute region-specific storage (e.g., based on the size returned by the query UVC). At block 920, the hypervisor issues an initialization to the secure interface control. In this regard, the hypervisor may issue an initialization UVC that provides donated storage to the UV control block that needs to coordinate between secure client configurations for the entire region. The initialization UVC specifies the base region-specific storage origin.

[0077] At block 925, the security interface control implements initialization (e.g., initializing UVC) by registering the donated storage with UV and marking it as secure. For initializing UVC, the security interface control may mark the donated storage as secure; allocate some of the donated storage for the regional security table; and register the donated storage for use by UV in the regional security table with a unique security domain, but no associated secure customer domain, and no associated host virtual address pair.

[0078] At box 930, the hypervisor reserves storage (e.g., base and variable secure guest domain specific storage). For example, the hypervisor reserves base and variable (e.g., based on the size of the secure guest domain storage) secure guest domain specific storage (e.g., the size returned by querying the UVC). At box 935, the hypervisor issues a create configuration to the secure interface control. At this point, the hypervisor may issue a create-secure-guest-config UVC that specifies the origin of the base and variable secure guest domain specific storage. In addition, the create-secure-guest-config UVC provides donated storage for the UV control blocks required to support such secure client configuration.

[0079] At block 940, the security interface control implements a create configuration (e.g., a UVC that creates a secure client configuration). For the UVC that creates a secure client configuration, the security interface control may mark the donated storage as secure; register the donated storage for use by the UV in a zone security table; and cause the donated storage to be registered with an associated secure client domain. The donated base (host absolute) storage is registered without an associated host virtual address pair. The donated variable (host virtual) storage is registered with an associated host virtual address pair.

[0080] At box 945, the hypervisor reserves the base secure client CPU specific storage (e.g., the size returned by the query UV). At box 950, the hypervisor specifies the storage origin. For example, the hypervisor issues a create secure client CPU to the UV that specifies the base secure client CPU specific storage origin. At box 955, the security interface control implements the create CPU (e.g., create secure client CPU UVC). For the create secure client CPU UVC, the security interface control can mark the donated storage as secure and register the donated storage for use by the UV in the region security table, but without an associated secure guest domain and without an associated host virtual address pair.

[0081] Now go to Fig.10 , according to one or more embodiments of the present invention, a process flow 1000 is generally shown for converting a non-secure hypervisor page to a secure page of a secure interface control. In the process flow 1000, three hypervisor pages (e.g., non-secure hypervisor page A, non-secure hypervisor page B, and non-secure hypervisor page C) are shown.

[0082] Hypervisor (non-secure) pages A, B, and C are accessible by non-secure entities (including the hypervisor). In addition, hypervisor (non-secure) pages A, B, and C are marked as non-secure (NS) and are listed in the region security table (e.g., Figure 1At arrow 1005, the initialization UVC is issued, which converts the client page A to the security interface control real storage page 1010 (UV2) associated with the entire region. The security interface control real storage 1010 can be marked as secure and registered in the regional security table (e.g., Figure 1 100) is registered as having no secure guest domain and hypervisor to host absolute (HV->HA) mapping in the zone security table 100 shown. Instead, it is registered with a unique UV2 security domain and the DA bit is set to 1. Note that the security interface control real storage 1010 can be accessed by the security interface control as real.

[0083] At arrow 1025, a Create SG Configuration or Create SG CPU UVC is issued from the hypervisor (non-secure) page B, which transfers the page to the secure interface control real storage 1030 (UVS) associated with the secure guest domain. The secure interface control real storage 1030 may be marked as secure and in the region security table (e.g., Figure 1 The UVs are registered in the region security table 100 as having an associated secure guest domain but without a hypervisor to host absolute (HV->HA) mapping (i.e., DA bit = 1) as having a UV associated with the host domain. Note that the secure interface control real storage 1010 can be accessed as real by the secure interface control on behalf of the secure guest domain.

[0084] At arrow 1045, the UVC that creates the SG configuration is issued from the hypervisor (non-secure) page C, which transfers the page to the secure interface control virtual storage 1050 associated with the secure guest domain (UVV). The secure interface control virtual storage 1050 can be marked as secure and in the region security table (e.g., Figure 1 The zone security table 100 shown is registered as a UV with a mapping of secure guest domain and hypervisor to host absolute (HV->HA). Note that the security interface control virtual storage 1050 is accessible as a UV virtual on behalf of the secure guest domain.

[0085] Now turn to Fig.11 , a process flow 1100 is depicted regarding secure storage access by a program or a secure interface control according to one or more embodiments. This represents a situation where a secure interface control is about to access client storage or secure interface control storage and the access must be properly marked to allow hardware to verify the security of the access. 1100 describes such marking of storage accesses by a secure interface control. Process flow 1100 begins at block 1110, where the secure interface control determines whether it is accessing secure interface control storage.

[0086] If this is not an access to the secure interface control storage, then process flow 1100 proceeds to decision block 1112 (as indicated by the "No" arrow). At decision block 1112, the secure interface control determines whether it is accessing secure client storage. If this is not an access to secure client storage, then process flow 1100 proceeds to "B" (which is connected to Fig.12 If this is an access to a secure client storage, then process flow 1100 proceeds to decision block 1113 where the security interface control determines if the default secure client domain is being used. If so, process flow 1100 proceeds to "B" (which is connected to Fig.12 If not, process flow 1100 proceeds to block 1114. At block 1114, the appropriate secure client domain is loaded into the SG secure domain register (and proceeds to "B", which is connected to Fig.12 Processing flow 1200).

[0087] If this is an access to secure interface control storage, process flow 1100 proceeds to block 1120 (as indicated by the "yes" arrow). At block 1120, the access is marked as secure UV (eg, using the UV security domain register).

[0088] Processing flow 1100 then proceeds to decision block 1130 where the security interface control determines if this is an access to UVV space (e.g., a variable table of an SG configuration). If it is an access to UVV space, processing flow 1100 proceeds to block 1134 (as indicated by the "yes" arrow). At block 1134, the access is marked as virtual. At block 1136, the applicable secure client domain is loaded into the UV security domain register. At block 1138, the DAT conversion and access storage are ready to begin. Returning to decision block 1130, if this is not an access to UVV space, processing flow 1100 proceeds to block 1140 (as indicated by the "no" arrow). At block 1140, the access is marked as real.

[0089] At decision block 1150, the security interface control determines if this is an access to UVS space (e.g., SG configuration or CPU table). If this is an access to UVS space, then process flow 1100 proceeds to block 1136 (as indicated by the "yes" arrow). If this is not an access to UVS space, then process flow 1100 proceeds to block 1170 (as indicated by the "no" arrow). Then, the access would be an access to UV2 space (e.g., zone security table). At block 1170, the unique UV2 security domain is loaded into the UV security domain register.

[0090] Fig.12 A process flow 1200 is depicted in accordance with one or more embodiments of the invention. When a client is dispatched, the SIE entry firmware may indicate to the hardware that the client is running (e.g., client mode active) and may indicate whether the client is secure. If the client is secure, the associated secure guest domain may be loaded into the hardware (e.g., in the SG security domain register). When a program is accessing storage, the hardware may mark the access based on the current state of the program at the time of the access. Fig.12 An example of this process in process flow 1200 is shown. At block 1205, the hardware can determine whether the machine is currently running in client mode, and if not, the access can be marked as a host access at block 1210, and the access can be marked as a non-secure access at block 1215. If the machine is running in client mode at block 1205, the access can be marked as a client access at block 1220, and it is further determined at block 1225 whether the current client is a secure client. If the client is non-secure, the access can be marked as non-secure at block 1215. If the client is secure, the hardware can mark the client as secure at block 1230, which can associate the secure client with the SG security domain register loaded when the secure client is dispatched. For both non-secure and secure clients, the DAT status can be checked at block 1235. If DAT is off, the access can be marked as real at block 1240. If DAT is on, the access can be marked as virtual at block 1245. After the access is marked as real at block 1240 if DAT is off, or as virtual at block 1245 if DAT is on, the hardware is ready to begin translating and accessing storage at block 1250, as shown in FIG. Fig.13 Further described in .

[0091] Fig.13An example of a conversion performed by hardware to support secure and non-secure access in a process flow 1300 according to one or more embodiments of the present invention is depicted. At block 1305, the hardware can determine whether the access is marked as a client conversion, and if so, and if the access is virtual at block 1310, the client DAT can be executed at block 1315. During the client DAT conversion, there can be a nested intermediate extraction for the client DAT table. If the original conversion is marked as secure, the table extraction can be marked as client real and secure. The table extraction can also follow the conversion process of the process flow 1300. After executing the client DAT for the access marked as client virtual at block 1315 and for any access marked as client real (virtual=no) at block 1310, the client prefix and client memory offset can be applied at block 1320. When the client conversion process is completed, if the original client conversion is marked as secure at block 1325, the resulting address can be marked as host virtual and secure. Process 1300 can continue for any access marked as host virtual. If the original access was a host access (client=no) at block 1305 and the host access was virtual at block 1330, a host DAT may be performed at block 1335. The host table fetch may be marked as non-secure at block 1335. After performing the host DAT at block 1335, or if the original host access was marked as real (virtual=no) at block 1330, host prefixing may be applied at block 1340. At block 1345, the resulting address may be a host absolute address.

[0092] Fig.14 An example of DAT conversion with secure storage protection that can be performed by hardware in a process flow 1400 according to one or more embodiments of the present invention is depicted. Fig.13 Continuing at block 1345 of , if a secure UV access is identified at block 1405, the hardware may verify at block 1410 whether the storage is registered as secure UV storage, and if not, present an error at block 1415. Secure UV access may be performed by the secure control interface when accessing UV storage. If the storage device is registered as secure UV storage at block 1410, protection checking may continue, as may be performed for any secure access except for the UV security domain register (set by the secure control interface before making a secure UV access) which may be used as a designated security domain for domain checking at block 1420, where processing continues. Additionally, any violation detected for UV access at block 1425 (entry point D) may be presented as an error at block 1430, rather than as an exception to the hypervisor at block 1435, as is done for secure client violations at block 1425 (secure UV=no).

[0093] For accesses that are not marked as secure UV accesses at block 1405, the hardware determines at block 1440 whether the access is a secure client access, and if not, and if the page is marked as secure at block 1445, an exception may be presented to the hypervisor at block 1435. Otherwise, if at block 1440 the access is not a secure client access and the page is not marked as secure at block 1445, then at block 1450 the conversion is successful.

[0094] If the access is a secure client access at block 1440, or the access is a secure UV access to storage that is registered as secure UV storage at block 1410, then at block 1420 the hardware may check to ensure that the storage is registered to the security entity associated with the access. If this is a secure UV access, then the specified security domain may be obtained from the UV security domain register (loaded by the security control interface based on the secure UV storage being accessed), and for secure client accesses, the specified security domain is obtained from the SG security domain register (loaded when the security entity is dispatched). If at block 1420, the storage being accessed is not registered to the specified security domain, then for the secure UV access at block 1425, an error is sent at block 1430, and for the secure client access at block 1425 (secure UV=no), an exception is presented to the hypervisor at block 1435.

[0095] For secure accesses to storage at blocks 1440 and 1410 (which is registered to the specified security domain at block 1420), if virtual address checking is disabled at block 1455, i.e., the DA bit = 1, and the access is real at block 1460, the translation is completed at block 1450. However, if the DA bit = 1 at block 1455, but the access is virtual (real = no) at block 1460, an error is sent at block 1430 for the secure UV access at block 1425, and an exception is presented to the hypervisor at block 1435 for the secure client access (secure UV = no) at block 1425. If the DA bit = 0 at block 1455 and the access is a virtual access at block 1475, the hardware can determine at block 1470 whether the host virtual to host absolute mapping of the access matches the mapping registered for the host absolute address. If so, the translation is successfully completed at block 1450. If the mapping does not match at block 1470, an error occurs at block 1430 for the secure UV access at block 1425, and an exception is presented to the hypervisor at block 1435 for the secure client access (Secure UV=No) at block 1425. If at block 1475 the DA bit=0 and the access is a real access (Virtual=No), an error occurs at block 1430 for the secure UV access at block 1425, and an exception is presented to the hypervisor at block 1435 for the secure client access (Secure UV=No) at block 1425; or, at block 1450, the translation may be completed successfully. At block 1480, any access by the I / O subsystem may check to see if the page is marked as secure at block 1445, and if the page is secure, an exception may be presented to the hypervisor at block 1435; if the page is not marked as secure, the translation is successful at block 1450.

[0096] Various checks of storage registration and mapping may be centrally managed through the zone security table interface 1485. For example, blocks 1410, 1420, 1455, 1470, and 1475 may interface with a zone security table associated with the same zone to manage various accesses.

[0097] Fig.15System 1500 is shown in accordance with one or more embodiments of the present invention. System 1500 (which may be any computing device as described herein) includes hardware 1501 supporting a processor 1502, a system memory 1503, and a security interface control 1530. Operating on hardware 1501 is a logical partition hypervisor 1510 supporting one or more untrusted entities (e.g., hypervisors represented by untrusted entities 1521 and 1522). Untrusted (e.g., non-secure) entity 1521 supports one or more secure entities (e.g., clients) (represented by security entity 1541a.0 through security entity 1541a.n, where n is an integer greater than 0). Similarly, untrusted entity 1522 supports one or more secure entities (represented by security entity 1542a.0 through security entity 1542a.n, where n is an integer greater than 0). Any of the hypervisors 1521 and 1522 and / or the security entities 1541 and 1542 may make a call (e.g., an instruction call) to the security interface control 1530. The hypervisors 1521 and 1522 and / or the security entities 1541 and 1542 may be considered to be software of the system 1500 that communicates with the security interface control 1530. In the context of the present patent, the described hypervisors correspond to the untrusted entities 1521 and 1522 and may also be referred to as a host or an operating system (OS). The LPAR hypervisor 1510 is part of the trusted firmware, although it is not necessarily part of the security interface control. The security entities 1541 and 1542 may also be referred to as clients, virtual machines (VMs), or containers.

[0098] As mentioned herein, the security interface control 1530 provides a secure interface between the hypervisors 1521 and 1522 and the security entities 1541 and 1542 to provide additional security by working in cooperation with the hardware 1501 and the millicode 1570. As shown, the security interface control 1530 is implemented in internal, secure and trusted hardware and / or firmware (e.g., residing on the hardware 1501 between the software and the hardware 1501 of the system 1500) to provide initialization and maintenance of the security environment, as well as coordination of the dispatch of these security entities on the hardware 1501. That is, the security interface control 1530 runs as a trusted portion of the lowest level firmware, so that each individual security entity 1541 and 1542 can use different parts of the data security storage, as strictly enforced by the hardware 1501.

[0099] Many of the machine's architected basic instructions or commands, such as move character length (MVCL) and start interpreted execution (SIE), are implemented in millicode 1570. In this context, millicode 1570 acts as an extension to hardware 1510 using a hardware interface (referred to herein as communication interface 1580) to provide implementation for more complex architected instructions (i.e., millicode instructions). The communication interface 1580 is optimized to provide entry and exit into "millicode" to implement these millicode instructions and functions. According to one or more embodiments, the secure interface control 1570 in turn utilizes the communication interface 1580, as many of the newly added functions required by the secure interface control 1530, such as secure SIE dispatch and UV call (UVC), are implemented in millicode 1570. Note that there is no "secure interface control mode." That is, the system 1500 does not enter and exit secure interface control mode, but rather millicode 1570 performs secure interface control functions as it would perform other functions in the system 1500. As a result, there is no transition between running as a secure interface control 1530 and running as "normal" millicode. Therefore, the technical effects and benefits of the embodiments herein include: the communication interface 1580 does not include any software context switches or any overhead associated with such context switches. In addition, the hardware 1501 maintains the "architected" state of the running client or hypervisor code and keeps it independent of the "temporary" millicode state. For example, the hardware 1501 continues to monitor and maintain interrupts at the architected client and / or hypervisor level that calls the secure interface control 1530.

[0100] According to one or more embodiments, when security entity 1541 or 1542 is dispatched by untrusted entity 1521 or 1522, the SIE entry millicode sets a new indication that the security entity is running and loads the secure client state including the security domain ID into hardware 1501. Hardware 1501 then uses the state to perform necessary security checks while the secure client domain is running.

[0101] Since millicode 1570 is already trusted firmware, millicode 1570 is able to "seamlessly" access client facilities, hypervisor facilities, and secure interface control facilities without switching modes. It can also access all storage devices (non-secure storage devices, secure storage devices associated with a specific secure client domain, and auxiliary secure storage devices that are sometimes also associated with a specific secure client domain). In one or more implementations, millicode 1570 does this by using extended hardware facilities that allow it to specify which type of storage device it wants to access so that the appropriate security checks can be completed by hardware 1501. These checks are performed even when the access is performed by the secure interface control 1530. The secure interface control 1530 utilizes these new mechanisms when executing UVC instructions and when interpreting certain other host or client instructions and functions (for example, some of the UVC commands call millicode 1570 for any access to a secure client or secure UV storage device).

[0102] Fig.16 Describes a method for Fig.15 Processing flow 1600 of the communication interface 1580 of FIG. Processing flow 1600 depicts the use of an existing millicode interface (eg, Fig.15 An example of a communication interface 1580) is shown in FIG. Fig.15 The hardware 1501 already maintains two separate contexts (architected and millicode).

[0103] Process flow 1600 begins at block 1610, where Fig.15 The system 1500 of the embodiment of the present invention executes architected instructions (e.g., MVCL or UVC). The architected instructions may originate from a program or software, such as a secure entity 1541, 1542 or an untrusted entity 1521, 1522. At decision block 1620, the communication interface 1580 determines whether the architected instruction is a millicode instruction. If the architected instruction is not a millicode instruction, the process flow 1630 proceeds to block 1640, where the architected instruction is directly executed by the hardware 1501 without any millicode control. The process then ends at block 1640.

[0104] If the architected instruction is a millicoded instruction, process flow 1630 proceeds to block 1650 where Fig.15 The communication interface 1580 of the present invention enters millicode. Entering millicode through 1580 includes: when the hardware 1501 is engaged through the communication interface 1580 to execute millicode instructions. At block 1660, Fig.15 The millicode 1570 executes millicode instructions.

[0105] At this point, Fig.15The security interface control 1580 executed in the hardware 1501 receives an architected instruction (e.g., UVC) from the hypervisors 1521 and 1522 and / or the security entities 1541 and 1542. At decision block 1620, the security interface control 1570 utilizes the communication interface 1580 to determine whether the architected instruction is a millicode instruction. Note that the millicode 1570 is an extension of the hardware that performs the functions of the security interface control when executing architected instructions. The communication interface 1580 has been enhanced to allow the millicode 1570 to access all storage devices in the secure execution context, including secure storage devices associated with a specific secure client domain (e.g., relative to the security entities 1541, 1542 associated with the architected instruction). The communication interface enhancement includes additional control bits that can be set by the millicode to specify secure access. In addition, when a secure client is dispatched, the security interface control executed in millicode can set an indication that the secure client is running and load the secure client state into the hardware. The secure dispatch code can easily access both the non-secure portion of the client state and the secure portion of the client state. At block 1670, Fig.15 The communication interface 1580 of the secure client exits millicode. The process then ends at block 1640. Furthermore, when the secure client domain associated with the secure client is running, the hardware continues to use the secure client state (even when not running in millicode) to perform security checks.

[0106] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings described herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

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

[0108] Features are as follows:

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

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

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

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

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

[0114] The service model is as follows:

[0115] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on the cloud infrastructure. The applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer neither manages nor controls the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

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

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

[0118] The deployment model is as follows:

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

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

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

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

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

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

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

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

[0127] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71 ; virtual storage 72 ; virtual networks 73 (including virtual private networks); virtual applications and operating systems 74 ; and virtual clients 75 .

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

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

[0130] Now turn to Fig.19, a system 1900 is depicted according to one or more embodiments of the present invention. The system 1900 includes an example node 10 (e.g., a hosting node) that communicates directly or indirectly with one or more client devices 20A-20E, for example, via a network 165. The node 10 may be a data center or host server of a cloud computing provider. The node 10 executes a hypervisor 12, which facilitates the deployment of one or more VMs 15 (15A-15N). The node 10 also includes a hardware / firmware layer 11 that provides direct support for the functions required by the VMs 15A-N and the hypervisor 12, and facilitates the hypervisor 12 to provide one or more services to the VMs 15. In the current implementation, communication is provided between the hardware / firmware layer 11 and the hypervisor 12, between the hardware / firmware layer 11 and the VMs 15, between the hypervisor 12 and the VMs 15, and between the hypervisor 12 and the VMs 15 via the hardware / firmware layer 11.

[0131] For example, the node 10 can facilitate the client device 20A to deploy one or more of the VMs 15A-15N. The VMs 15A-15N can be deployed in response to respective requests from different client devices 20A-20E. For example, VM 15A can be deployed by the client device 20A, VM 15B can be deployed by the client device 20B, and VM 15C can be deployed by the client device 20C. The node 10 can also facilitate the client to provide a physical server (not running as a VM). The example described here concretizes the resource provision in the node 10 as part of a VM, however, the described technical solution can also be applied to the resource provision as part of a physical server.

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

[0133] The client device 20A from the client devices 20A-20e is a communication device, such as a computer, a smart phone, a tablet computer, a desktop computer, a laptop computer, a server computer, or any other communication device that requests the deployment of a VM by the hypervisor 12 of the node 10. The client device 20A can send the request via the network 165 to be received by the hypervisor. VM 15A in VM15A-15N is a VM image deployed by the hypervisor 12 in response to the request from the client device 20A in the client devices 20A-20e. The hypervisor 12 is a VM monitor (VMM), which can be software, firmware, or hardware that creates and runs VMs. The hypervisor 12 facilitates the VM 15A to use the hardware components of the node 10 to execute programs and / or store data. With appropriate features and modifications, the hypervisor 12 can be an IBM Oracle's VM Server, Citrix's XenServer, Vmware's ESX, Microsoft Hyper-V hypervisor or any other hypervisor. The hypervisor 12 may be a native hypervisor executing directly on the node 10, or a hosted hypervisor executing on another hypervisor.

[0134] Now go to Fig. 20 , a node 10 for implementing the teachings herein is shown according to one or more embodiments of the present invention. The node 10 may be an electronic computer framework that includes and / or employs any number of computing devices as described herein and networks utilizing various communication technologies and combinations thereof. The node 10 may be easily scalable, extensible, and modular, with the ability to change to different services or reconfigure some features independently of other features.

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

[0136] Fig. 20 The node 10 includes a hard disk 2007, which is an example of a tangible storage medium that can be executed by the processor 2001. The hard disk 2007 stores software 2008 and data 2009. The software 2008 is stored as instructions executed by the processor 2001 on the node 10 to perform operations such as reference. Figure 1-Figure 19 Data 2009 includes values ​​of a set of qualitative or quantitative variables organized in various data structures to support the operation of software 2008 and be used by it.

[0137] Fig. 20 The node 10 includes one or more adapters (e.g., hard disk controller, network adapter, graphics adapter, etc.) that interconnect and support communication between the processor 2001, the system memory 2003, the hard disk 2007, and other components (e.g., peripherals and external devices) of the node 10. In one or more embodiments of the present invention, the one or more adapters may be connected to one or more I / O buses that are connected to the system bus 2002 via an intermediate bus bridge, and the one or more I / O buses may utilize a common protocol, such as a peripheral component interconnect (PCI).

[0138] As shown, the node 10 includes an interface adapter 2020 that interconnects a keyboard 2021, a mouse 2022, a speaker 2023, and a microphone 2024 to a system bus 2002. The node 10 includes a display adapter 2030 that interconnects the system bus 2002 to a display 2031. The display adapter 2030 (and / or the processor 2001) may include a graphics controller to provide graphics performance, such as display and management of a GUI 2032. The communication adapter 2041 interconnects the system bus 2002 with a network 2050, so that the node 10 can communicate with other systems, devices, data, and software such as a server 2051 and a database 2052. In one or more embodiments of the present invention, the operation of the software 2008 and the data 2009 may be implemented on the network 2050 by the server 2051 and the database 2052. For example, network 2050, server 2051, and database 2052 may combine to provide internal iterations of software 2008 and data 2009 as platform as a service, software as a service, and / or infrastructure as a service (e.g., as a network application in a distributed system).

[0139] The embodiments described herein are necessarily rooted in computer technology, and in particular computer servers that host VMs. Furthermore, one or more embodiments of the present invention facilitate improvements to the operation of computing technology itself, particularly computer servers that host VMs, by facilitating computer servers that host VMs to host secure VMs, wherein even hypervisors are prohibited from accessing memory, registers, and other such data associated with secure VMs. Furthermore, one or more embodiments of the present invention provide an important step toward improvements to VMs that host computing servers by using secure interface controls (also referred to herein as "hyper monitors" or "UVs") that include hardware, firmware (e.g., millicode), or a combination thereof to facilitate separation of secure VMs and hypervisors, and thereby maintain security of VMs hosted by computing servers. The secure interface controls provide lightweight intermediate operations to facilitate security without adding substantial overhead to protecting VM state during initialization / exit of the VM as described herein.

[0140] Embodiments of the invention disclosed herein may include systems, methods and / or computer program products (herein systems) that implement a communication interface of a secure interface control. Note that for each description, element identifiers are reused for other similar elements of different drawings.

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

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

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

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

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

[0146] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage medium used here should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse transmitted by a fiber optic cable), or an electrical signal transmitted by a wire.

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

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

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

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

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

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

[0153] The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the present 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 "include" and / or "comprise" specify the presence of the 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.

[0154] Descriptions of various embodiments have been presented herein for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies available on the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for a communication interface of a secure interface control, comprising: A secure client domain is created by a secure interface control of a computer, and a secure entity associated with the secure client domain calls the secure interface control, wherein the secure interface control includes a hardware mechanism, the hardware mechanism prevents a storage location assigned to the secure entity from being accessed by other secure entities and unsecure entities, the hardware mechanism includes a regional security table, the regional security table includes an address of the storage location; receiving, by a communication interface of the secure interface control executed between the secure interface control and computer hardware, instructions to perform functions of the secure interface control, wherein the instructions are from a non-secure entity including a hypervisor, the instructions including architectural instructions; Determining, by the communication interface, that the instruction is a millicoded instruction; entering millicode via the communication interface, the entering millicode comprising enabling the security interface control to engage the millicode of the hardware via the communication interface based on the instruction being the millicoded instruction, wherein access by the millicode to any storage location of the zone security table is controlled by the hardware; and The instructions are executed by the millicode, wherein the instructions include instructions configured to import a secure guest page as part of the hypervisor import page.

2. The method according to claim 1, wherein: The instructions are configured to schedule the security entity and set an indication that the security entity is running, and load client state into hardware, and the hardware performs security checks using the secure client state when the secure client domain associated with the security entity is running.

3. The method according to claim 1 or 2, wherein: After the instructions are executed by the millicode, the communication interface exits the millicode.

4. The method according to claim 2, further comprising: accessing, in the secure client state, a page previously called out by the hypervisor; as well as A host page fault is presented by the hardware to the hypervisor.

5. The method according to claim 4, wherein: The method further includes: identifying, by the hypervisor, non-secure host absolute pages available to the guest pages; Using the hypervisor, loading the encrypted guest page into the identified host absolute page; and The guest pages are mapped in the host DAT table by the hypervisor.

6. The method according to claim 1 or 2, wherein: The millicode utilizes the enhancements of the communication interface to access secure storage associated with the instructions in a secure execution context.

7. The method according to claim 1 or 2, wherein: The millicode is an extension of the hardware that performs the functionality of the secure interface control when executing the instructions.

8. The method according to claim 5, further comprising: reassigning, by the hypervisor, a secure client; as well as Pages that were previously paged out by the hypervisor are re-accessed by the secure client.

9. The method according to claim 8, further comprising: A non-secure storage access exception is presented by the hardware to the host.

10. A computer program product, comprising a computer-readable storage medium, wherein the computer-readable storage medium has program instructions embodied therein, wherein the program instructions can be executed by a computer to cause operations, wherein the operations include: A secure client domain is created by a secure interface control of a computer, and a secure entity associated with the secure client domain calls the secure interface control, wherein the secure interface control includes a hardware mechanism, the hardware mechanism prevents a storage location assigned to the secure entity from being accessed by other secure entities and unsecure entities, the hardware mechanism includes a regional security table, the regional security table includes an address of the storage location; receiving, by a communication interface of the secure interface control executed between the secure interface control and computer hardware, instructions to perform functions of the secure interface control, wherein the instructions are from a non-secure entity including a hypervisor, the instructions including architectural instructions; Determining, by the communication interface, that the instruction is a millicoded instruction; entering millicode via the communication interface, the entering millicode comprising enabling the security interface control to engage the millicode of the hardware via the communication interface based on the instruction being the millicoded instruction, wherein access by the millicode to any storage location of the zone security table is controlled by the hardware; and The instructions are executed by the millicode, wherein the instructions include instructions configured to import a secure guest page as part of the hypervisor import page.

11. The computer program product according to claim 10, wherein: The instructions are configured to schedule the security entity and set an indication that the security entity is running, and load client state into hardware, and the hardware performs security checks using the secure client state when the secure client domain associated with the security entity is running.

12. The computer program product according to claim 10 or 11, wherein: After the instructions are executed by the millicode, the communication interface exits the millicode.

13. The computer program product of claim 11, wherein: The operations also include: accessing, in the secure client state, a page previously paged out by the hypervisor; and A host page fault is presented by the hardware to the hypervisor.

14. The computer program product of claim 13, wherein: The operations also include: identifying, by the hypervisor, non-secure host absolute pages available to the guest pages; Using the hypervisor, loading the encrypted guest page into the identified host absolute page; and The guest pages are mapped in the host DAT table by the hypervisor.

15. The computer program product according to claim 10 or 11, wherein: The millicode utilizes the enhancements of the communication interface to access secure storage associated with the instructions in a secure execution context.

16. The computer program product according to claim 10 or 11, wherein: The millicode is an extension of the hardware that performs the functionality of the secure interface control when executing the instructions.

17. The computer program product of claim 14, wherein: The operations also include: reassigning, by the hypervisor, a secure client; and Pages that were previously paged out by the hypervisor are re-accessed by the secure client.

18. The computer program product of claim 17, wherein: The operations also include: A non-secure storage access exception is presented by the hardware to the host.

19. A system for a communication interface of a secure interface control, comprising: Including millicode hardware; Security interface controls; a communication interface of the security interface control executed between the security interface control and the hardware; Wherein, the system is executable to cause operations, the operations comprising: A secure client domain is created by a secure interface control of a computer, and a secure entity associated with the secure client domain calls the secure interface control, wherein the secure interface control includes a hardware mechanism, the hardware mechanism prevents a storage location assigned to the secure entity from being accessed by other secure entities and unsecure entities, the hardware mechanism includes a regional security table, the regional security table includes an address of the storage location; receiving, by the communication interface, instructions to perform a function of a secure interface control, wherein the instructions are from a non-secure entity including a hypervisor, and the instructions include architectural instructions; Determining, by the communication interface, that the instruction is a millicoded instruction; entering millicode via the communication interface, the entering millicode comprising enabling the security interface control to engage the millicode of the hardware via the communication interface based on the instruction being the millicoded instruction, wherein access by the millicode to any storage location of the zone security table is controlled by the hardware; and The instructions are executed by the millicode, wherein the instructions include instructions configured to import a secure guest page as part of the hypervisor import page.

20. The system of claim 19, wherein: The instructions are configured to schedule the security entity and set an indication that the security entity is running, and load client state into hardware, and the hardware performs security checks using the secure client state when the secure client domain associated with the security entity is running.

21. The system according to claim 19 or 20, wherein: After the instructions are executed by the millicode, the communication interface exits the millicode.

22. The system of claim 20, wherein: The operations also include: accessing, in the secure client state, a page previously paged out by the hypervisor; and A host page fault is presented by the hardware to the hypervisor.

23. The system of claim 22, wherein: The operations also include: identifying, by the hypervisor, non-secure host absolute pages available to the guest pages; Using the hypervisor, loading the encrypted guest page into the identified host absolute page; Mapping the client page in the host DAT table by the virtual machine hypervisor; reassigning, by the hypervisor, a secure client; re-accessing, by the secure client, pages that had been previously paged out by the hypervisor; and A non-secure storage access exception is presented by the hardware to the host.

24. The system of claim 19 or 20, wherein: The millicode utilizes the enhancements of the communication interface to access secure storage associated with the instructions in a secure execution context.

25. The system of claim 19 or 20, wherein: The millicode is an extension of the hardware that performs the functionality of the secure interface control when executing the instructions.

Images