Storage Sharing between a Secure Domain and an Unsecure Entity

Abstract

According to one or more embodiments of the present invention, a computer-implemented method includes, through the control of a security interface of a computer system, marking a memory page as insecure based on the security storage protection indicator of the page being cleared, enabling an insecure entity of the computer system to access the memory page shared between the insecure entity and the secure domain of the computer system. The security interface control may verify that the security storage protection indicator of the page is cleared before allowing the insecure entity to access the page. The security interface control may provide access to the page to a secure entity of the secure domain without checking the security storage protection indicator of the page.

Description

Background Art

[0001] The present invention generally relates to computer technology and, more particularly, to storage sharing between a secure domain and an unsecure entity.

[0002] Cloud computing and cloud storage provide users with the ability to store and process their data in a third-party data center. Cloud computing facilitates the ability to quickly and easily provision VMs to customers without the customers having to purchase hardware or provide floor space for physical servers. Customers can easily scale VMs up or down according to the customers' changing preferences or requirements. Typically, a cloud computing provider provisions VMs that physically reside on servers at the provider's data center. Customers generally care about the security of the data in the VMs, especially since a computing provider typically stores data for more than one customer on the same server. Customers may expect security between their own code / data and the code / data of the cloud computing provider, as well as between their own code / data and the code / data of other VMs running at the provider's site. In addition, customers may expect security from the provider's administrators and protection against potential security vulnerabilities from other code 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 isolation. The widespread use of virtualization in implementing cloud infrastructure has led to unique security issues for customers of cloud services because virtualization changes the relationship between the operating system (OS) and the underlying hardware (whether its 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 hypervisor depends on the hypervisor to transparently provide virtualization services to the guest. These services include memory management, instruction emulation, and interrupt handling.

[0005] In the case of memory management, a VM can move its data from disk (page in) to reside in memory, and the VM can also move its data back (page out) to disk. When a page resides in memory, the VM (guest) uses dynamic address translation (DAT) to map the page in memory from the guest virtual address to the guest absolute address. In addition, the hypervisor has its own DAT mapping for the guest pages in memory (from the host virtual address to the host absolute address), and it can independently and transparently to the guest page the guest pages in and out of memory. Through the host DAT table, the hypervisor provides memory isolation or shares guest memory between two separate guest VMs. The host is also able to access guest memory to simulate guest operations on behalf of the guest when necessary. Summary of the Invention

[0006] According to one or more embodiments of the present invention, a computer-implemented method includes, through the control of a security interface of a computer system, enabling an insecure entity of the computer system to access a page of a memory shared between the insecure entity and a security domain of the computer system based on the page being marked as insecure due to the security storage protection indicator of the page being cleared. The security interface control may verify that the security storage protection indicator of the page is cleared before allowing the insecure entity to access the page. The security interface control may provide access to the page to a secure entity of the security domain without checking the security storage protection indicator of the page. Advantages may include storage sharing between the security domain and the insecure entity.

[0007] According to additional or alternative embodiments of the present invention, before providing access to a page to a secure entity, the security interface control may verify that a dynamic address translation mapping established by the insecure entity and used by the secure entity has not changed. Advantages may include ensuring that the address translation used by the secure entity is not modified by the insecure entity.

[0008] According to additional or alternative embodiments of the present invention, the security interface control may receive a request from a secure entity to establish shared access to a page. The security interface control may determine whether the page is currently identified as secure by the security storage protection indicator being set and the page is registered to the security domain of the secure entity. The security interface control may register the page to the security domain as shared based on determining that the page is identified as secure and registered to the security domain of the secure entity. Advantages may include tracking the storage protection status and page registration.

[0009] According to additional or alternative embodiments of the present invention, the security interface control may lock the page based on determining that the page is currently identified as secure, registered to the security domain of the secure entity, and the page is not currently locked. The security interface control may prevent a secure entity or the security interface control in a different context from accessing the page when the page is locked. Advantages may include restricting access to secure pages under certain conditions.

[0010] According to additional or alternative embodiments of the present invention, the security interface control may perform one or more authorization checks or status updates on the page when the page is locked. The security interface control may unlock the page based on completing one or more authorization checks or status updates on the page. Advantages may include managing the authorization checks of the page.

[0011] According to additional or alternative embodiments of the present invention, a busy indicator may be sent to the secure entity based on determining that the page has been locked before receiving a request to establish shared access to the page. Advantages may include controlling the notification timing.

[0012] According to additional or alternative embodiments of the present invention, the security domain may be checked and updated by a section security table including a security domain identifier associated with the page and virtual address mapping data associated with the page. Advantages may include managing the states of multiple pages and regions.

[0013] According to additional or alternative embodiments of the present invention, the secure storage protection indicator may include bits in the hardware of a computer system for each of multiple pages of memory. Advantages may include managing the storage protection indicators of the memory.

[0014] According to additional or alternative embodiments of the present invention, the secure interface control may be firmware, hardware, or a combination of firmware and hardware. The insecure entity may be a hypervisor. The secure entity may be a virtual machine that is a secure guest hosted by the hypervisor in a security domain. Advantages may include sharing secure pages from the secure entity with the insecure entity.

[0015] Other embodiments of the present invention implement the features of the above method in a computer system and a computer program product.

[0016] Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the present invention are described in detail herein and are considered to be a part of the present invention. To better understand the advantages and features of the present invention, reference is made to the specification and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 A section security table according to one or more embodiments of the present invention is described;

[0019] Figure 2 The virtual and absolute address spaces for performing DAT according to one or more embodiments of the present invention are described;

[0020] Figure 3 A multi-part DAT for supporting nested virtual machines (VMs) running under a hypervisor according to one or more embodiments of the present invention is depicted;

[0021] Figure 4 The mapping of secure guest storage according to one or more embodiments of the present invention is depicted;

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

[0023] Figure 6 Shows a system schematic diagram of a secure interface control memory according to one or more embodiments of the present invention;

[0024] Figure 7 Depicts a process flow of an import operation according to one or more embodiments of the present invention;

[0025] Figure 8 Depicts a process flow of an import operation according to one or more embodiments of the present invention;

[0026] Figure 9 Depicts a process of a donation memory operation according to one or more embodiments of the present invention;

[0027] Figure 10 Depicts a process flow of the conversion from an insecure hypervisor page to a secure page controlled by a secure interface according to one or more embodiments of the present invention;

[0028] Figure 11 Depicts a process flow of secure storage access by a secure interface control according to one or more embodiments of the present invention;

[0029] Figure 12 Depicts a process flow of access annotation by a secure interface control and by hardware according to one or more embodiments of the present invention;

[0030] Figure 13 Depicts a process flow for supporting the conversion between secure and insecure accesses of a program and a secure interface control according to one or more embodiments of the present invention;

[0031] Figure 14 Depicts a process flow of a DAT for secure storage protection through a program and through a secure interface control according to one or more embodiments of the present invention;

[0032] Figure 15 Illustrates a processing flow for shared access storage protection according to one or more embodiments of the present invention;

[0033] Figure 16 Depicts a processing flow for storage sharing between a secure domain and an insecure entity according to one or more embodiments of the present invention;

[0034] Figure 17 Illustrates a cloud computing environment according to one or more embodiments of the present invention;

[0035] Figure 18 Depicts an abstract model layer according to one or more embodiments of the present invention;

[0036] Figure 19depicts a system according to one or more embodiments of the present invention; and

[0037] Figure 20 depicts a processing system according to one or more embodiments of the present invention.

[0038] The figures depicted herein are illustrative. Many variations may be made to the figures or operations described herein without departing from the spirit of the present invention. For example, these actions may be performed in a different order, or actions may be added, deleted, or modified. Similarly, the term "coupled" and its variants describe having a communication path between two elements and do not imply a direct connection between these elements without intermediate elements / connections therebetween. All such variations are considered to be part of the specification. Detailed Description

[0039] One or more embodiments of the present invention utilize an efficient, lightweight secure interface control between software and a machine to provide additional security.

[0040] A virtual machine (VM) running as a guest under the control of a hypervisor relies on the hypervisor to transparently provide virtualization services to the guest. These services can be applied to any interface between a secure entity and another untrusted entity that traditionally allows this other entity to access secure resources. As previously mentioned, these services can include, but are not limited to, memory management, instruction emulation, and interrupt handling. For example, for interrupt and exception injection, the hypervisor typically reads and / or writes to the guest's prefix area (low core). 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.). A VM is maintained as software executing on an underlying host (physical processor or processor group). From the perspective of a user or software resource, a VM appears to be its own independent physical machine. As used herein, the terms "hypervisor" and "VM monitor (VMM)" refer to a processing environment or platform service that manages and permits multiple VMs to execute on the same host using multiple (and sometimes different) OSs. It should be understood that deploying a VM includes the installation process of the VM and the activation (or power-on) process of the VM. In another example, deploying a VM includes the activation (or power-on) process of the VM (e.g., in the case where the VM was previously installed or already exists).

[0041] To facilitate and support secure guests, there are technical challenges where additional security is required between the hypervisor and the secure guest without relying on the hypervisor, such that the hypervisor cannot access data from the VM and thus cannot provide services in the manner described above.

[0042] The secure execution described herein provides hardware mechanisms to ensure isolation between secure storage and unsecure storage, and between secure storage belonging to different secure users. For secure guests, additional security is provided between the "untrusted" unsecure hypervisor and the secure guests. To do this, many functions that the hypervisor typically performs on behalf of the guests need to be incorporated into the machine. A new secure interface control (also referred to herein as "UV") is described herein for providing a secure interface between the hypervisor and the secure guests. The terms secure interface control and UV are used interchangeably herein. The secure interface control works in cooperation with the hardware to provide this additional security. In addition, a lower-level hypervisor can provide virtualization for the untrusted hypervisor, and if the lower-level hypervisor is implemented in trusted code, it can also be part of the secure interface control.

[0043] In one example, the secure interface control is implemented in internal, secure, and trusted hardware and / or firmware. The trusted firmware can include, for example, processor millicode or PR / SM logical partition code. For secure guests or entities, the secure interface control provides the initialization and maintenance of the secure environment and the coordination of the dispatch of these secure entities on the hardware. When a secure guest actively uses data and it resides in the host storage, it remains "in the clear" in the secure storage. The secure guest storage can be accessed by that single secure guest - this is strictly enforced by the hardware. That is, the hardware prevents any unsecure entity (including the hypervisor or other unsecure guests) or different secure guests from accessing the data. In this example, the secure interface control runs as the lowest-level trusted part of the firmware. The lowest level or millicode is actually an extension of the hardware and is used to implement complex instructions and functions defined, for example, in from IBM. The millicode is able to access all parts of the storage, which in the context of secure execution includes its own secure UV storage, unsecure hypervisor storage, secure guest storage, and shared storage. This allows it to provide any function that a secure guest or hypervisor needs to support that guest. The secure interface control also has direct access to the hardware, which allows the hardware to effectively provide security checks under the control of conditions established by the secure interface control.

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

[0045] Similar to many other architected instructions, these UVC commands can be executed by machine firmware. Instead of the machine entering the security interface control mode, the machine performs the security interface control functions in the mode it is currently running. The hardware maintains both the firmware and software states, so there is no context switch to handle these operations. This low overhead allows for tight binding and cooperation between different layers of software, trusted firmware, and hardware in a way that minimizes and reduces the complexity of the security interface control while still providing the necessary level of security.

[0046] According to one or more embodiments of the present invention, when supporting the security interface control and the control block structure required for the hardware to properly maintain secure guests and the hypervisor environment, the hypervisor donates storage to the security interface control while initializing the secure guest environment. Thus, when preparing to 1) initialize the area to run the secure guest, 2) create a secure guest domain, and 3) create secure CPUs to run in each domain, the hypervisor issues a query UVC instruction to determine the amount of storage required for donation, etc. Once the storage has been donated, it is marked as secure and registered as belonging to the security interface control; and access by any insecure or secure guest entity is prohibited. This is maintained until the associated entity (e.g., the secure guest CPU, the secure guest domain, or the area) is destroyed.

[0047] In one example, a first section of the UV storage for supporting zone - specific UV control blocks is donated to the security interface control as part of initializing the UVC and resides in a portion herein referred to as the UV2 storage. Second and third portions of the UV storage for supporting base and variable security - guest - configuration control blocks (for each security guest domain) are donated as part of creating - security - guest - configuration UVCs and reside in the UVS and UVV storages respectively. Fourth and final segments of the UV storage for supporting security - CPU control blocks also reside in the UVS space and are donated as part of creating - security - guest - CPU UVCs. When each of these regions is donated, the security control interface marks them as secure (to prevent them from being accessed by any insecure entity) and also registers them in the zone security table as belonging to the security interface control (to prevent them from being accessed by any security guest entity). To provide further isolation within the UV space, the UV2 space (which is not associated with any dedicated security guest domain) is also labeled with a unique UV2 security domain, while both the UVS and UVV spaces are further labeled with the associated dedicated security guest domains. In this example, the UVV space resides in the host virtual space and can thus be further identified with a host virtual - to - host absolute mapping.

[0048] Although the security interface control is able to access all storage (insecure storage, security guest storage, and UV storage), one or more embodiments of the present invention provide mechanisms that allow the security interface control to access the UV storage very specifically. Using the same hardware mechanisms that provide isolation between security guest domains, embodiments of the present invention can provide similar isolation within the UV storage. This ensures that the security interface control accesses the UV storage only when expected and specified; accesses only the security guest storage for the desired specified security guest; and accesses the insecure memory only when specified. That is, the security interface control can very specifically specify the storage it intends to access such that the hardware can ensure that it indeed accesses that storage. Additionally, it can be specified that it is only intended to access the UV storage associated with the specified security guest domain.

[0049] To provide security, the security interface control working with the hardware provides and ensures the decryption and encryption of data when the hypervisor transparently pages in and out security guest data. To achieve this, when paging in and out guest security data, the hypervisor needs to issue new UVCs. Based on the controls set by the security interface control during these new UVCs, the hardware will ensure that these UVCs are indeed issued by the hypervisor.

[0050] In this new security environment, whenever the hypervisor pages out a secure page, a new translation needs to be issued from the secure store (export) UVC. In response to this export UVC, the security interface control will 1) indicate that the page is UV "locked", 2) encrypt the page, 3) set the page to insecure, and 4) reset the UV lock. Once the export UVC is complete, the hypervisor can now page in the encrypted guest page.

[0051] Additionally, whenever the hypervisor pages in a secure page, it must issue a new translation to the secure store (import) UVC. In response to this import UVC, the UV or the security interface control will 1) mark the page as secure in hardware, 2) indicate that the page is UV "locked", 3) decrypt the page, 4) set the permissions for a specific secure guest domain, and 5) reset the UV lock. Whenever a secure entity makes an access, the hardware performs a permission check on the page during the translation. These checks include: 1) a check to verify that the page actually belongs to the secure guest domain attempting to access it; and 2) a check to ensure that the hypervisor has not changed the host mapping of this page while the page has resided in the guest memory. Once the page is marked as secure, the hardware prevents the hypervisor or an insecure guest VM from accessing any secure page. Additional translation steps prevent access by another secure VM and prevent remapping by the hypervisor.

[0052] One or more embodiments of the present invention enable secure guests to share pages with the hypervisor. The security interface control can provide one or more sharing commands, such as a define-share-store command or a make-share command. For a shared page, the security interface control can assign the page to a single secure guest configuration and mark the page as insecure. Secure guest access can continue to verify that the page has not been remapped or reassigned to a different guest by the hypervisor. The security interface control can provide isolation between the shared stores of different secure guest configurations while allowing hypervisor access.

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

[0054] Further, as Figure 1As shown, the zone security table 100 includes a security domain ID 120 (identifying the security domain associated with this page); a UV bit 130 (indicating that this 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 cases, 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 sharing of the page with an insecure hypervisor); and a host virtual address 160 (indicating the host virtual address registered for this host absolute address, which is referred to as a host-address pair). Note that the host-address pair indicates the host absolute and the associated, registered host virtual address. Once imported by the hypervisor, the host-address pair represents the mapping of the page, and the comparison ensures that the host does not remap the page while the guest is using the page.

[0055] Dynamic Address Translation (DAT) is used to map virtual storage to real storage. When a guest VM runs as a pageable guest under the control of the hypervisor, the guest uses DAT to manage the pages resident in its memory. Additionally, when the pages are resident in its memory, the host independently uses DAT to manage those guest pages (along with its own pages). The hypervisor uses DAT to provide isolation and / or sharing of storage between different VMs and to prevent guest access to hypervisor storage. When the guest runs in an insecure mode, the hypervisor is able to access all guest storage.

[0056] DAT enables isolation of one application from another while still allowing them to share common resources. Moreover, it allows the implementation of VMs that can be used for designing and testing new versions of the OS as well as concurrent processing of application programs. A virtual address identifies a location in virtual storage. An address space is a contiguous sequence of virtual addresses together with dedicated translation parameters (including the DAT table) that allow each virtual address to be translated into an associated absolute address, which identifies the address in terms of a byte location in storage.

[0057] DAT uses multi-table lookups to translate virtual addresses into associated absolute addresses. This table structure is typically defined and maintained by a storage manager. This storage manager transparently shares absolute storage among multiple programs, for example, by paging out one page to bring in another page. When a page is paged out, the storage manager will set an invalid bit in the associated page table, for example. When a program attempts to access a paged-out page, the hardware will present the storage manager with a program interrupt commonly referred to as a page fault. In response, the storage manager will page in the requested page and reset the invalid bit. This is all done transparently to the program and allows the storage manager to virtualize storage and share storage among various different users.

[0058] When a virtual address is used by the CPU to access main storage, it is first converted to a real address by the DAT and then to an absolute address by a prefix. The specification (origin and length) of the highest level table for a particular address space is called an address - space - control element (ASCE) and defines the associated address space.

[0059] Now turn to Figure 2 , according to one or more embodiments of the present invention, an example virtual address spaces 202 and 204 for performing the DAT and an absolute address space 206 are generally shown. In Figure 2 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 using ASCE A 208 in a multi - table (segment 230 and page tables 232a, 232b) lookup. Similarly, virtual pages B1.V214b1 and B2.V 214b2 are mapped to absolute pages B1.A 222b1 and B2.A 222b2 respectively using ASCE B 210 in a two - table 234 and 236 lookup.

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

[0061] Embodiments of the invention described herein provide secure visitor and UV storage protection. Unsecure visitors and the hypervisor are prohibited from accessing secure storage. The hypervisor dictates that for a given resident secure visitor page, the following occurs. The associated host absolute address is accessible only through a single hypervisor (host) DAT mapping. That is, there is a single host virtual address mapped to any given host absolute address assigned to the secure visitor. The hypervisor DAT mapping (host virtual to host absolute) associated with a given secure visitor page does not change when it is page-in. The host absolute page associated with a secure visitor page is mapped for a single secure visitor.

[0062] According to one or more embodiments of the present invention, storage sharing between secure guests is also prohibited. Under the control of a secure guest, storage is shared between a single secure guest and the hypervisor. The UV storage is secure storage and can be controlled by the secure interface rather than guest / host access. The storage is allocated by the hypervisor to the secure interface for control. According to one or more embodiments of the present invention, the hardware and the secure interface control prohibit any attempt to violate these rules.

[0063] Now turning to Figure 4 , an example of the mapping of secure guest storage is generally shown according to one or more embodiments of the present invention. Figure 4 Similar to Figure 3 , except that Figure 4 's example does not allow storage sharing between secure guest A and secure guest B. In Figure 3 's insecure example, both the host virtual address A2.HV 340a2 belonging to guest A and the B2.HV360b2 belonging to guest B are mapped to the same host absolute page AB2.HA 380. In Figure 4 's secure guest storage example, the host virtual address A2.HV 340a2 belonging to guest A is mapped to the host absolute address A2.HA 490a, while the B2.HV360b2 belonging to guest B is mapped to its own B2.HA 490b. In this example, there is no sharing between secure guests.

[0064] When a secure guest page resides on disk, it is encrypted. When the hypervisor pages into a secure guest page, it issues a UV call (UVC), which causes the secure interface control to mark the page as secure (unless shared), decrypt the page (unless shared), and register the page (in the zone security table) as belonging to the appropriate secure guest (e.g., guest A). In addition, it registers the associated host virtual address (e.g., A3.HV 340a3) to the host absolute page (referred to as the host-address pair). If the hypervisor fails to issue the correct UVC, it receives an exception when attempting to access the secure guest page. When the hypervisor pages out a guest page, a similar UVC is issued, which encrypts the guest page (unless shared), marks the guest page as insecure, and registers it as insecure in the zone security table.

[0065] In an example with five given host absolute pages K, P, L, M, and N, each of the host absolute pages is marked as secure by the secure interface control when the hypervisor pages them in. This prevents insecure guests and the hypervisor from accessing them. When paged in by the hypervisor, host absolute pages K, P, and M are registered as belonging to guest A; when paged in by the hypervisor, host absolute pages L and N are registered as belonging to guest B. Shared pages (pages shared between a single secure guest and the hypervisor) are not encrypted or decrypted during paging. They are not marked as secure (permitted for hypervisor access) in the zone security table, but are registered in a single secure guest domain.

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

[0067] According to one or more embodiments, when a secure entity attempts to access a page, the hardware performs an additional translation check to verify that the storage truly belongs to that particular secure guest. If not, an insecure access (PIC3E) exception is presented to the hypervisor. Additionally, if the translated host virtual address does not match the host virtual address of the host-address pair registered in the zone security table, a secure storage violation (‘3F’x) exception is identified. To enable sharing with the hypervisor, a secure guest can access storage that is not marked as secure as long as the translation check permits access.

[0068] Now turning to Figure 5 , according to one or more embodiments of the present invention, a system schematic 500 generally showing DAT operations is illustrated. System schematic 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 the hypervisor (host) absolute address space 530. For example, Figure 5Illustrated is the sharing of host absolute storage by two different host virtual address spaces, and also illustrated is the sharing of one of those host virtual addresses not only between two guests but also additionally with the host itself. In this regard, the host primary virtual address space 510 and the host home virtual address space 520 are examples of two host virtual address spaces, each of which is addressed by a separate ASCE, the host primary ASCE (HPASCE) 591 and the host home ASCE (HHASCE) 592, respectively. Note that all secure interface control storage (virtual and real) is donated by the hypervisor and is marked as secure. Once donated, the secure interface control storage can be accessed only by the secure interface as long as the associated secure entity exists.

[0069] As shown, the host primary virtual address space 510 includes guest A absolute page A1.HV, guest A absolute page A2.HV, guest 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.

[0070] According to one or more embodiments of the present invention, in the zone security table described herein, all secure guests (e.g., secure guest A and secure guest B) are stored and registered as belonging to the secure guest configuration, and the associated host virtual addresses (e.g., A1.HV, A2.HV, B1.HV) are also registered as part of the host-address pair. In one or more embodiments, all secure guest storage is mapped in the host primary virtual space. Additionally, all secure interface control storage is also registered in the zone security table as belonging to the secure interface control and can be further differentiated in the zone security table based on the associated secure guest domain. According to one or more embodiments of the present invention, the UV virtual storage is mapped in the host home 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 does not have an associated host virtual mapping, and the DA bit in the zone security table (which indicates that virtual address comparison is disabled) is set to indicate this. The host storage is marked as insecure and is also registered as insecure in the zone security table.

[0071] Thus, in the case of "guest absolute = host virtual", the hypervisor (host) main DAT table (defined by HPASCE591) converts the pages of the host main virtual address space 510 as follows: The guest A absolute page A1.HV is mapped to the host absolute A1.HA belonging to the secure guest A; the guest A absolute page A2.HV is mapped to the host absolute page A2.HA belonging to the secure guest A; the guest B absolute page B1.HV is mapped to the host absolute page B1.HA belonging to the secure guest B; and the host virtual page H3.HV is mapped to the host absolute page H3.HA of the insecure host (and there is no host-address pair as it is insecure). Further, the hypervisor (host) attribution DAT table (defined by HHASCE 592) converts the pages of the host attribution virtual address space 520 as follows: The secure interface control virtual page U1.HV is mapped to the host absolute page U1.HA defined as secure UV virtual; the host virtual page H1.HV is mapped to the host absolute page H1.HA defined as insecure; and the host virtual page H2.HV is mapped to the host absolute page H2.HA defined as insecure. There are no host-address pairs associated with H1.HA or H2.HA as they are insecure.

[0072] In operation, if a secure guest attempts to access a secure page allocated to the secure interface control, the hardware presents a secure store violation ('3F'X) exception to the hypervisor. If an insecure guest or the hypervisor attempts to access any secure page (including those allocated to the secure interface control), the hardware presents a secure store access ('3D'X) exception to the hypervisor. Alternatively, an error condition can be presented for an attempted access made to the secure interface control space. If the hardware detects a mismatch in the secure allocation on a secure interface control access (e.g., a store registered in the zone security table as belonging to a secure guest rather than to the secure interface control, or a mismatch in the host-address pair used with the registered pair), a check is presented.

[0073] In other words, the host main virtual address space 510 includes host virtual pages A1.HV and A2.HV (belonging to secure guest A) and B1.HV (belonging to secure guest B), which are respectively mapped to host absolutes A1.HA, A2.HA, and B1.HA. In addition, the host main virtual address space 510 includes a host (hypervisor) page H3.HV, which is mapped to host absolute H3.HA. The host home virtual space 520 includes two host virtual pages H1.HV and H2.HV that are mapped to host absolute pages H1.HA and H2.HA. Both the host main virtual address space 510 and the host home virtual address space 520 are mapped into a single host absolute 530. The storage pages belonging to secure guest A and secure guest B are marked as secure and are registered in the Figure 1 zone security table 100 shown. On the other hand, the host storage is marked as insecure. When the hypervisor defines these secure guests, it must donate the host storage to the secure interface control for use in the secure control blocks required to support these secure guests. This storage can be defined in host absolute or host virtual space, and in one example, specifically, in the host home virtual space. Returning to Figure 5 , the host absolute pages U1.HA and U2.HA secure UV absolute are defined as secure-interface-control storage of the host absolute storage. Thus, these pages are marked as secure and are registered in the Figure 1 zone security table 100 shown as belonging to the secure interface control and having an associated security domain. Since the pages are defined as host absolute addresses, there is no associated host virtual address, so the DA bit is set in the zone security table 100.

[0074] After conversion, an example of the hypervisor (host) absolute address space 530 can be found in Figure 6 . Figure 6 FIG. 600 is a system schematic diagram depicting secure interface control storage in accordance with one or more embodiments of the present invention. System schematic diagram 600 shows a hypervisor (host) absolute address space 630, which includes host absolute page A2.HA for secure guest A (for A2.HV); host absolute page B1.HA for secure guest B (for B1.HV); host absolute page H1.HA insecure (host); host absolute page H2.HA insecure (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 for secure guest A (for A1.HV).

[0075] Now turning to Figure 7, according to one or more embodiments of the present invention, a process flow 700 for an import operation is generally shown. When a secure guest accesses a page called up by a hypervisor page, an event sequence such as that shown in process flow 700 occurs in order to securely bring the page back. The process flow 700 begins at block 705, where the secure guest accesses a guest virtual page. Since the page is, for example, invalid, the hardware presents a host page fault indicated by the program interrupt code 11 (PIC 11) to the hypervisor

[0076] (see block 715). The hypervisor then identifies an available, insecure host absolute page for the guest page (see block 720) and loads the encrypted guest page into the identified host absolute page (see block 725).

[0077] At block 730, the host absolute page is then mapped into the appropriate (host virtual address-based) host DAT table. At block 735, the hypervisor host then reschedules the secure guest. At block 740, the secure guest re-accesses the guest secure page. The page fault no longer exists, but since this is a secure guest access and the page is not marked as secure in the secure table 100 of FIG. 100, at block 745, the hardware presents an insecure storage exception (PIC3E) to the hypervisor. This PIC3E prevents the guest from accessing this secure page until the necessary import has been issued. Next, the process flow 700 proceeds to "A", which connects to Figure 8 .

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

[0079] As part of the import UVC, the trusted firmware acting as secure interface control checks to see if this page has been locked by the secure 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 will delay in response (see block 825) and reissue the import UVC (the process flow 800 returns to block 805). If the page has not been locked, the process flow 800 proceeds to decision block 822.

[0080] At decision block 822, the security interface control checks to see if the page is a page shared with an insecure hypervisor. If it is shared (process flow 800 advances to decision block 824), the security interface control registers the host absolute address, along with the associated secure guest domain and host virtual address, in the zone security table as shared. The page remains marked as insecure. This completes the import of the UVC, and the page is now available for access by the guest. Processing continues, with the hypervisor re-dispatching the guest (block 830) and the secure guest successfully accessing the page (block 835).

[0081] If the host virtual page to be imported is not shared with the hypervisor (process flow 800 advances to block 840), the security interface control will mark the page as secure, such that the hypervisor can no longer access the page. At block 845, the security interface control locks the page such that no other UVC can modify the page state. Once the lock is set (at block 850), the security interface control verifies that the content of the guest page has not changed while it was encrypted. If they have changed, an error return code is returned to the hypervisor, otherwise, the security interface control decrypts the secure page.

[0082] At block 855, the security interface control unlocks the page, allowing access by other UVCs, 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 guest to access and completes the UVC.

[0083] Now turning to Figure 9 , in accordance with one or more embodiments of the present invention, a process flow 900 regarding donated memory operations is generally shown. 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). This data can include the amount of base zone-dedicated host-absolute storage required; the amount of base secure-guest-domain-dedicated host-absolute storage required; the amount of variable secure-guest-domain-dedicated host-virtual storage required per MB; and / or the amount of base secure-guest-CPU-dedicated host-absolute storage required.

[0084] At block 915, the hypervisor reserves the base host-absolute zone-dedicated storage (e.g., based on the size returned by the query UVC). At block 920, the hypervisor issues an initialization to the security interface control. In this regard, the hypervisor can issue an initialization UVC that provides the donated storage for the UV control blocks required for coordination between the secure guest configurations for the entire zone. The initialization UVC specifies the source of the base zone-dedicated storage.

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

[0086] At block 930, the hypervisor reserves storage (e.g., base and variable security-guest-domain-specific storage). For example, the hypervisor reserves base and variable (e.g., based on the size of the security-guest-domain storage) security-guest-domain-specific storage (e.g., the size returned by querying the UVC). At block 935, the hypervisor issues a create configuration to the security interface control. In this regard, the hypervisor can issue a create-security-guest-configuration UVC that specifies the base and variable security-guest-domain-specific storage sources. Further, the create-security-guest-configuration UVC provides the donated storage for the UV control blocks required to support the security guest configuration.

[0087] At block 940, the security interface control implements the create configuration (e.g., the create-security-guest-configuration UVC). For the create-security-guest-configuration UVC, the security interface control can mark the donated storage as secure; register the donated storage in the zone security table for use by the UV; and register the donated storage in an associated security-guest-domain. The donated base (host-absolute) storage is registered as not having an associated host-virtual address pair. The donated variable (host-virtual) storage is registered with an associated host-virtual address pair.

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

[0089] Now turn to Figure 10, According to one or more embodiments of the present invention, a processing flow 1000 generally showing the transformation of an insecure hypervisor page to a secure page of a secure interface control is presented. In the process flow 1000, three hypervisor pages (e.g., insecure hypervisor page A, insecure hypervisor page B, and insecure hypervisor page C) are shown.

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

[0091] At arrow 1025, a create-SG-configuration or create-SG-CPUUVC is issued from the hypervisor (insecure) page B, which transitions the page to a secure interface control real storage 1030 (UVS) associated with a secure guest domain. The secure interface control real storage 1030 can be marked as secure and is registered as UV with an associated secure guest domain in the zone security table (e.g., Figure 1 the zone security table 100 shown in ), and has no hypervisor-to-host absolute (HV->HA) mapping (i.e., DA bit = 1). 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.

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

[0093] Now go toFigure 11 depicts process flow 1100 regarding secure storage access controlled by a program or a security interface, in accordance with one or more embodiments. This represents a scenario where the security interface control is about to access the guest storage or the security interface control storage and must correctly label the access to allow the hardware to verify the security of the access. 1100 describes the storage access labeled by the security interface control. The process flow 1100 starts at block 1110, where the security interface control determines whether it is accessing the security interface control storage.

[0094] If this is not an access to the security interface control storage, then the process flow 1100 proceeds to decision block 1112 (as indicated by the "No" arrow). At decision block 1112, the security interface control determines whether it is accessing the secure guest storage. If this is not an access to the secure guest storage, then the process flow 1100 proceeds to "B" (which is connected to Figure 12 process flow 1200), which will use default settings for an insecure access. If this is an access to the secure guest storage, then the process flow 1100 proceeds to decision block 1113, where the security interface control determines whether the default secure guest domain is being used. If so, then the process flow 1100 continues to proceed to "B" (which is connected to Figure 12 process flow 1200), which will use default settings for a secure guest access. If not, then the process flow 1100 proceeds to block 1114. At block 1114, the appropriate secure guest domain is loaded into the SG-Security-Domain register (and proceeds to "B", which is connected to Figure 12 process flow 1200).

[0095] If this is an access to the security interface control storage, then the process flow 1100 proceeds to block 1120 (as indicated by the "Yes" arrow). At block 1120, the access is labeled as secure UV (e.g., using the UV-Security-Domain register).

[0096] The process flow 1100 then proceeds to decision block 1130, where the security interface control determines whether this is an access to the UVV space (e.g., the SG-Configuration Variable Table). If it is an access to the UVV space, then the process flow 1100 proceeds to block 1134 (as indicated by the "Yes" arrow). At block 1134, the access is labeled as virtual. At block 1136, the applicable secure guest domain is loaded into the UV-Security-Domain register. At block 1138, the DAT conversion and access storage preparation begin. Returning to decision block 1130, if this is not an access to the UVV space, then the process flow 1100 proceeds to block 1140 (as indicated by the "No" arrow). At block 1140, the access is labeled as real.

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

[0098] Figure 12 Depicts a process flow 1200 in accordance with one or more embodiments of the present invention. When a guest is dispatched, the SIE entry firmware can indicate to the hardware that a guest is running (e.g., guest mode active) and can indicate whether the guest is secure. If the guest is secure, the associated secure guest domain can be loaded into the hardware (e.g., in the SG security domain register). When a program accesses storage, the hardware can label the access based on the program's current state at the time of access. Figure 12 Shows an example of this process in the process flow 1200. At block 1205, the hardware can determine whether the machine is currently running in guest mode, and if not, can label the access as a host access at block 1210 and as an insecure access at block 1215. If the machine is running in guest mode at block 1205, the access can be labeled as a guest access at block 1220 and it can be further determined at block 1225 whether the current guest is a secure guest. If the guest is not secure, at block 1215, the access can be labeled as insecure. If the guest is secure, the hardware can label the guest as secure at block 1230, which can associate the secure guest with the SG - security - domain register loaded when the secure guest was dispatched. For both insecure and secure guests, the DAT status can be checked at block 1235. If the DAT is off, at block 1240, the access can be labeled as real. If the DAT is on, at block 1245, the access can be labeled as virtual. Once the access is labeled as real at block 1240 with the DAT off, or labeled as virtual at block 1245 with the DAT on, the hardware is ready to begin the translation and access to storage at block 1250, as Figure 13 further described in.

[0099] Figure 13Depicts an example of the conversion accomplished by hardware according to one or more embodiments of the present invention to support both secure and insecure accesses in process flow 1300. At block 1305, the hardware can determine whether the access is labeled as a guest conversion, and if so, and if the access is virtual at block 1310, then the guest DAT can be executed at block 1315. During the guest DAT conversion, there can be nested intermediate fetches for the guest DAT table. If the original conversion is labeled as secure, the table fetch can be labeled as guest-real and secure. The table fetch can also follow the conversion process of process flow 1300. After the guest DAT is executed for an access labeled as guest-virtual at block 1315 and for any access labeled as guest-real at block 1310 (virtual = no), the guest prefix and guest memory offset can be applied at block 1320. When the guest conversion process is complete, at block 1325, if the original guest conversion is labeled as secure, the resulting address can be labeled as host-virtual and secure. For any access labeled as host-virtual, process 1300 can continue. If the original access is a host access at block 1305 (guest = no) and is virtual at block 1330, then the host DAT can be executed at block 1335. At block 1335, the host table fetch can be marked as insecure. After the host DAT is executed at block 1335, or if the original host access is labeled as real at block 1330 (virtual = no), then the host prefix can be applied at block 1340. At block 1345, the resulting address can be a host absolute address.

[0100] Figure 14 Describes an example of a DAT conversion with secure storage protection in process flow 1400 that can be performed by hardware according to one or more embodiments of the present invention. Continuing from Figure 13 block 1345, if a secure UV access is identified at block 1405, the hardware can verify at block 1410 whether the storage is registered as secure UV storage, and if not, present an error at block 1415. When accessing the UV storage, the secure interface control can perform a secure UV access. If the storage is registered as secure UV storage at block 1410, then in addition to the UV-secure-domain register (set by the secure interface control prior to the secure UV access) being used as the designated secure domain for the domain check at block 1420 (where processing continues), the protection check can continue as performed for any secure access. Additionally, any violation detected for the UV access at block 1425 (entry point D) can be presented as an error at block 1430, rather than presenting an exception to the hypervisor at block 1435 as done for a secure guest violation at block 1425 (secure-UV = no).

[0101] For an access not labeled as secure-UV access at block 1405, the hardware determines at block 1440 whether the access is a secure guest access, and if not, and if the page is marked as secure at block 1445, an exception can be presented to the hypervisor at block 1435. Otherwise, if the access is not a secure guest access at block 1440 and the page is not marked as secure at block 1445, the translation is successful at block 1450.

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

[0103] For secure access to storage at boxes 1440 and 1410 registered to a specified security domain at box 1420, if virtual address checking is disabled, i.e., DA bit = 1 at box 1455 and the access is real at box 1460, then the translation is completed at box 1450. However, if the DA bit = 1 at box 1455 but the access is virtual (real = no) at box 1460, then for the secure-UV access at box 1425, an error is given at box 1430, and for the secure-guest access at box 1425 (secure-UV = no), an exception is presented to the hypervisor at box 1435. If the DA bit = 0 at box 1455 and the access at box 1475 is a virtual access, then at box 1470 the hardware can determine whether the host virtual to host absolute mapping of the access matches the mapping registered for that host absolute address. If so, the translation is successfully completed at box 1450. If the mapping does not match at box 1470, then for the secure-UV access at box 1425, an error is given at box 1430, and for the secure-guest access at box 1425 (secure-UV = no), an exception is presented to the hypervisor at box 1435. If the DA bit = 0 and the access at box 1475 is a real access (virtual = no), then for the secure-UV access at box 1425, an error is given at box 1430, and for the secure-guest access at box 1425 (secure-UV = no), an exception is presented to the hypervisor at box 1435; alternatively, the translation can be successfully completed at box 1450. Any access made by the I / O subsystem at box 1480 can be checked to see if the page is marked as secure at box 1445, and if the page is secure, then an exception can be presented to the hypervisor at box 1435; if the page is not marked as secure, then the translation is successful at box 1450.

[0104] The different checks for storage registration and mapping can be jointly managed through the zone security table interface 1485. For example, boxes 1410, 1420, 1455, 1470, and 1475 can interface with the zone security table associated with the same zone to manage different accesses.

[0105] Now turning Figure 15 , a processing flow 1500 for shared access storage protection is generally shown in accordance with one or more embodiments of the present invention. At box 1505, if it is planned to share a memory page but the content is secret, such as as part of memory management rather than shared data content, then a security entity (such as a secure guest) can encrypt the memory page. The encryption can be provided as a service controlled by the security interface, or the secure guest can choose to implement a separate encryption process.

[0106] At Figure 15In the example of , at block 1510, the security entity may issue a set-shared-access command to the security interface control. The set-shared-access command may be received at the security interface control as a request from the security entity to establish shared access to the page. At block 1515, the security interface control may determine whether the page is currently identified as secure by having a secure storage protection indicator set (e.g., SSP=1), and at block 1520, determine whether the page is registered with the security domain of the security entity that issued the command. The security interface control may register the page with the security domain as shared based on determining at block 1515 that the page is identified as secure and registered with the security domain of the security entity at block 1520. At block 1530, the security interface control may lock the page based on determining that the page is currently identified as secure (block 1515), registered with the security domain of the security entity (block 1520), and that the page has not been locked (block 1525). The security interface control may prevent a security entity or security interface control that attempts to manage the same security page from accessing the page when the page is locked. For example, the security interface control can prevent the security entity and / or security interface control from attempting to access the page when the page is locked by changing the page registration on different processors and / or in different contexts. When the page is locked, one or more authorization checks and / or status updates of the page can be performed by the security interface control. The authorization check and status update can include, for example, checks and updates related to the integrity state of the machine, which is used to maintain and detect changes to encrypted content when the management program calls content pages in and out of the memory. At box 1535, the page can be unlocked based on completing one or more authorization checks on the page, and the page can be registered with the security domain as a share. At box 1540, the page can be marked as unsafe.

[0107] In some embodiments, if encryption is required, block 1505 may be performed later in process flow 1500 at a point after the page is locked but before the page is shared and marked as unsafe. At block 1545, a busy indicator may be sent to the security entity based on determining that the page has been locked before receiving a request to establish shared access to the page (block 1525=yes). The busy indicator may be delayed at block 1550, for example, to provide additional time for previously issued commands to complete and slow down the retry rate. The delay may be performed by a security interface control or a security guest. If the page is not registered with a security domain (block 1520=no) or the page is unsafe (block 1515=no) and the page is shared (block 1560=yes), an error may be reported at block 1555. If the page is unsafe (block 1515=no) and the page is not shared (block 1560=no), an exception may be raised to the unsafe entity at block 1555.

[0108] Now turning to Figure 16 , process flow 1600 for storage sharing between a secure domain and an unsecure entity is generally illustrated in accordance with one or more embodiments of the present invention. Process flow 1600 is Figure 15 a variant of process flow 1500.

[0109] At block 1605, the secure interface control of a computer system can be marked as unsecure based on a page-by-page secure storage protection indicator being cleared (e.g., SSP = 0) such that an unsecure entity of the computer system can access a page of memory shared between the unsecure entity and the secure domain of the computer system. At block 1610, the secure interface control can verify that the secure storage protection indicator of the page is cleared before allowing the unsecure entity to access the page. The secure storage protection indicator can be a bit in the hardware of the computer system for each of a plurality of pages of memory. The unsecure entity can be a hypervisor, and the secure entity can be a virtual machine that is a secure guest hosted by the hypervisor in the secure domain. At block 1615, the secure interface control can provide access to the page to the secure entity of the secure domain without checking the secure storage protection indicator of the page (e.g., without checking SSP).

[0110] The memory mapping test of the host address can still be performed as part of the access verification, but avoiding the check of SSP can further enhance the processing speed while ensuring that the unsecure entity cannot access the secure storage. The secure interface control can verify that the dynamic address translation mapping established by the unsecure entity and used by the secure entity has not changed before providing access to the page to the secure entity. The secure domain can be checked and updated by a section security table (such as Figure 1 section security table 100) that includes a secure domain identifier associated with the page and virtual address mapping data associated with the page.

[0111] It should be understood that although the present disclosure includes a detailed description of cloud computing, the implementation of the teachings recited herein is not limited to a cloud computing environment. Instead, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

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

[0113] The characteristics are as follows:

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

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

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

[0117] Rapid elasticity: In some cases, capabilities can be rapidly and elastically provisioned, scaled out quickly and in, and released quickly to scale in. To the consumer, the capabilities available for provisioning generally appear to be infinite and can be purchased in any quantity at any time.

[0118] Measured service: The cloud system automatically controls and optimizes resource use 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 the provider and the consumer of the used service.

[0119] The service models are as follows:

[0120] Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. These applications can be accessed from different client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control 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.

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

[0122] Infrastructure as a Service (IaaS): The ability provided to the consumer is to provide processing, storage, networking, and other fundamental computing resources that enable the consumer to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0123] The deployment models are as follows:

[0124] Private cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0125] Community cloud: The cloud infrastructure is shared by multiple organizations and supports a specific community with common concerns (e.g., missions, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0126] Public cloud: The cloud infrastructure is available to the public or a large industry group and is owned by the organization that sells the cloud services.

[0127] Hybrid cloud: The cloud infrastructure is composed of two or more clouds (private, community, or public), which remain unique entities but are bound together through standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

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

[0129] Now refer to Figure 17 , which depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, and local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or in-vehicle computer systems 54N, can communicate with the cloud computing nodes 10. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as in the private cloud, community cloud, public cloud, or hybrid cloud or a combination thereof described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, and cloud consumers do not need to maintain resources on their local computing devices. It should be understood that Figure 17The type of computing devices 54A-N shown is only illustrative, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network addressable connection (e.g., using a web browser).

[0130] Now referring to Figure 18 , a set of functional abstraction layers provided by cloud computing environment 50 ( Figure 17 ) is shown. It should be understood in advance that Figure 18 the components, layers, and functions shown are only illustrative, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

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

[0132] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

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

[0134] The workload layer 90 provides examples of functions that can utilize the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: maps and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and control of access to secure storage associated with virtual machines 96. It should be understood that these are merely some examples, and in other embodiments, the layer can include different services.

[0135] Now turn to Figure 19 which depicts a system 1900 in accordance with one or more embodiments of the present invention. The system 1900 includes, for example, an exemplary node 10 (e.g., a hosting node) that communicates directly or indirectly with one or more client devices 20A - 20E via a network 165. The node 10 can be a data center or a host server of a cloud computing provider. The node 10 executes a hypervisor 12 that facilitates the deployment of one or more VMs 15 (15A - 15N). The node 10 also includes a hardware / firmware layer 13 that includes a security interface control 11. The security interface control 11 includes one or more hardware modules and firmware that facilitate the hypervisor 12 providing one or more services to the virtual machines 15. There is communication between the hypervisor 12 and the security interface control 11; between the security interface control 11 and one or more VMs 15; between the hypervisor 12 and one or more VMs 15; and from the hypervisor 12 to the VMs 15 via the security interface control 11. To facilitate a secure VM environment, the hosting node 10 in accordance with one or more embodiments of the present invention does not include any direct communication between the hypervisor 12 and one or more VMs 15.

[0136] For example, the hosting node 10 can facilitate the deployment of one or more of the VMs 15A - 15N by the client device 20A. The VMs 15A - 15N can be deployed in response to corresponding requests from different client devices 20A - 20E. For example, the VM 15A can be deployed by the client device 20A, the VM 15B can be deployed by the client device 20B, and the VM 15C can be deployed by the client device 20C. The node 10 can also facilitate the client provisioning of a physical server (not running as a VM). The examples described herein specify the provisioning of resources in the node 10 as part of a VM, however, the described techniques can also be applied to the provisioning of resources as part of a physical server.

[0137] In an example, the client devices 20A - 20E can belong to the same entity, such as an individual, an enterprise, a government agency, a department within a company, or any other entity, and the node 10 can operate as a private cloud for the entity. In this case, the node 10 only hosts the VMs 15A - 15N deployed by the client devices 20A - 20E belonging to the entity. In another example, the client devices 20A - 20E can belong to different entities. For example, a first entity can own the client device 20A, while a second entity can own the client device 20B. In this case, the node 10 can be operated as a public cloud hosting VMs from different entities. For example, the VMs 15A - 15N can be deployed in a shielded manner, where the VM 15A does not facilitate access to the VM 15B. For example, the node 10 can use IBM z Processor Resource / System Manager (PR / SM) logical partitioning (LPAR) features to cover VM15A - 15N. These features (such as PR / SM LPAR) provide isolation between partitions, thus facilitating Node 10 to deploy two or more VMs 15A - 15N for different entities on the same physical Node 10 in different logical partitions. The PR / SM LPAR hypervisor is implemented in trusted internal firmware with specific hardware to provide this isolation.

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

[0139] Now turning to Figure 20 , according to one or more embodiments of the present invention, Node 10 for implementing the teachings herein is shown. Node 10 can be an electronic computer framework that includes and / or employs any number and combination of computing devices and networks using different communication technologies as described herein. Node 10 can be easily scalable, extensible, and modular, with the ability to change to different services or reconfigure some features independently of others.

[0140] In this embodiment, node 10 has a processor 2001, which may include one or more central processing units (CPUs) 2001a, 2001b, 2001c, etc. The processor 2001 (also referred to as a processing circuit, microprocessor, computing unit) is coupled to the system memory 2003 and different 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 node 10. The RAM is a read-write memory coupled to the system bus 2002 for use by the processor 2001.

[0141] Figure 20 Node 10 of Figure 20 includes a hard disk 2007, which is an example of a tangible storage medium that can be read-executed by the processor 2001. The hard disk 2007 stores software 2008 and data 2009. The software 2008 is stored as instructions to be executed by the processor 2001 on node 10 (for performing processes, such as the processes described in Figures 1 - 20 ). The data 2009 includes a set of values of qualitative or quantitative variables organized in different data structures to support the operation of the software 2008 and used by the operation of the software 2008.

[0142] Figure 20 Node 10 of Figure 20 includes one or more adapters (such as a 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 of node 10 (such as peripheral devices and external devices). In one or more embodiments of the present invention, 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 one or more I / O buses may utilize a common protocol, such as Peripheral Component Interconnect (PCI).

[0143] As shown in the figure, node 10 includes an interface adapter 2020 that interconnects a keyboard 2021, a mouse 2022, speakers 2023, and a microphone 2024 to the system bus 2002. 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 the display and management of the GUI 2032. A communication adapter 2041 interconnects the system bus 2002 with a network 2050, enabling node 10 to 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 software 2008 and data 2009 may be implemented by the server 2051 and the database 2052 over the network 2050. For example, the network 2050, the server 2051, and the database 2052 may be combined to provide internal iterations of the software 2008 and the data 2009, as platform as a service, software as a service, and / or infrastructure as a service (e.g., as a web application in a distributed system).

[0144] The embodiments described herein necessarily have their roots in computer technology and, specifically, in computer servers that host VMs. Further, one or more embodiments of the present invention facilitate improvements in the operation of computing technology itself (specifically, computer servers that host VMs) by enabling a computer server that hosts VMs to host a secure VM, where even the hypervisor is prohibited from accessing the memory, registers, and other such data associated with the secure VM. Additionally, one or more embodiments of the present invention provide important steps towards improving VM-hosting computing servers by using a security interface control that includes hardware, firmware (e.g., microcode), or a combination thereof (also referred to herein as "UV"), facilitating the separation of the secure VM and the hypervisor and thus maintaining the security of the VMs hosted by the computing server. The security interface control provides lightweight intermediate operations to facilitate security without adding a large overhead to the secure VM state during the initialization / exit of the VM as described herein.

[0145] Embodiments of the present invention disclosed herein may include systems, methods, and / or computer program products (herein, systems) that control access to secure storage of VMs. Note that for each explanation, the identifiers of the elements are reused for other similar elements in different figures.

[0146] The different embodiments of the present invention are described herein with reference to the related drawings. Alternative embodiments of the present invention may be designed without departing from the scope of the present invention. Various connection and positional relationships (e.g., above, below, adjacent, etc.) are set forth between elements in the following description and the drawings. Unless otherwise stated, these connections and / or positional relationships may be direct or indirect, and the present invention is not intended to be limited in this regard. Thus, 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, the various tasks and process steps described herein may be incorporated into a more comprehensive program or process having additional steps or functions not described in detail herein.

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

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

[0149] The terms "about", "substantially", "approximately" and their variants are intended to include the degree of error associated with the measurement of a particular quantity based on the equipment available at the time of filing of the present application. For example, "about" can include a range of ±8% or 5%, or 2% of a given value.

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

[0151] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium can 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 disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card or raised structures in a groove having instructions recorded thereon), and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0152] 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 transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0153] The computer-readable program instructions for performing the operations of the present technical solution may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, an electronic circuit (including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA)) may execute the computer-readable program instructions by using the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform various aspects of the present technical solution.

[0154] Aspects of the present technical solution will be described herein with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the technical solution. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0155] 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, which is executed by the processor of the computer or other programmable data processing device to create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing device, and / or other devices to act in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

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

[0157] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present technical solution. In this regard, each box in the flowchart or block diagram may represent a module, segment, or portion of an instruction that includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the boxes may occur out of the order noted in the figures. For example, two boxes shown in succession may, depending on the functionality involved, actually be executed substantially concurrently, or the boxes may sometimes be executed in the reverse order. It will also be noted that each box of the block diagrams and / or flowcharts, and combinations of boxes in the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware that performs the specified functions or actions or that performs a combination of dedicated hardware and computer instructions.

[0158] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. 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 the terms "comprises" and / or "comprising" are used in this specification, they specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

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

Claims

1. A method for storage sharing between a secure domain and an insecure entity, comprising: Controlling, by a security interface of a computer system, receiving a request to establish shared access to a page of a memory from a secure entity; Controlling, by the security interface, determining whether the page is currently identified as secure by being set with a secure storage protection indicator and the page is registered to a secure domain of the secure entity; Based on determining that the page is identified as secure and is registered to the secure domain of the secure entity, controlling, by the security interface, registering the page to the secure domain as shared; Based on the page being marked as insecure by having its secure storage protection indicator cleared, controlling, by the security interface, enabling an insecure entity of the computer system to access the page shared between the insecure entity and the secure domain of the computer system; Before allowing the insecure entity to access the page, controlling, by the security interface, verifying that the secure storage protection indicator of the page is cleared; and Controlling, by the security interface, providing access to the page to the secure entity of the secure domain without checking the secure storage protection indicator of the page.

2. The method according to claim 1, further comprising: Before providing access to the page to the secure entity, controlling, by the security interface, verifying that a dynamic address translation mapping established by the insecure entity and used by the secure entity has not changed.

3. The method according to claim 1, further comprising: Based on determining that the page is currently identified as secure, registered to the secure domain of the secure entity, and the page is not currently locked, controlling, by the security interface, locking the page; And Controlling, by the security interface, preventing the secure entity or the security interface control in a different context from accessing the page when the page is locked.

4. The method according to claim 3, further comprising: When the page is locked, controlling, by the security interface, performing one or more authorization checks or status updates on the page; And Based on completing the one or more authorization checks or status updates on the page, controlling, by the security interface, unlocking the page.

5. The method according to claim 3, further comprising: Based on determining that the page was locked before receiving the request to establish shared access to the page, sending a busy indicator to the secure entity.

6. The method according to claim 1, wherein Checking and updating the secure domain through a zone security table, the zone security table including a secure domain identifier associated with the page and virtual address mapping data associated with the page.

7. The method according to claim 1, wherein The secure storage protection indicator includes bits in the hardware of the computer system for each page of the memory.

8. The method according to claim 1, wherein The security interface control includes firmware, hardware, or a combination of firmware and hardware; the insecure entity includes a hypervisor; and the secure entity includes a virtual machine, the virtual machine being a secure guest hosted by the hypervisor in the secure domain.

9. A system for storage sharing between a secure domain and an unsecure entity, comprising: A memory; And A secure interface control of a processing unit configured to perform a plurality of operations, the plurality of operations including: receiving a request from a secure entity to establish shared access to a page of the memory; Determining whether the page is currently identified as secure by being set with a secure storage protection indicator and the page is registered to the secure domain of the secure entity; Based on determining that the page is identified as secure and is registered to the secure domain of the secure entity, registering the page to the secure domain as shared; Based on the page being marked as insecure by the secure storage protection indicator of the page being cleared, enabling the unsecure entity to access the page shared between the unsecure entity and the secure domain of the system; Before allowing the unsecure entity to access the page, verifying that the secure storage protection indicator of the page is cleared; and Providing access to the page to the secure entity of the secure domain without checking the secure storage protection indicator of the page.

10. The system according to claim 9, wherein The secure interface control is configured to perform operations, the operations including: Before providing access to the page to the secure entity, verifying that the dynamic address translation mapping established by the unsecure entity and used by the secure entity has not changed.

11. The system according to claim 9, wherein, The secure interface control is configured to perform operations, the operations including: Based on determining that the page is currently identified as secure, is registered to the secure domain of the secure entity, and the page is not currently locked, locking the page; and Preventing the secure entity or the secure interface control in different contexts from accessing the page when the page is locked by the secure interface control.

12. The system according to claim 11, wherein, The secure interface control is configured to perform operations, the operations including: Performing one or more authorization checks or status updates of the page when the page is locked; and Based on completing the one or more authorization checks or status updates of the page, unlocking the page.

13. The system according to claim 11, wherein, The secure interface control is configured to perform operations, the operations including: Based on determining that the page has been locked before receiving the request to establish shared access to the page, sending a busy indicator to the secure entity.

14. The system according to claim 9, wherein, Checking and updating the secure domain through a zone security table, the zone security table including a secure domain identifier associated with the page and virtual address mapping data associated with the page.

15. The system according to claim 9, wherein, The secure storage protection indicator includes bits in the hardware of the system for each page of the plurality of pages of the memory.

16. The system according to claim 9, wherein, The secure interface control includes firmware, hardware, or a combination of firmware and hardware; the unsecure entity includes a hypervisor; and the secure entity includes a virtual machine, the virtual machine being a secure guest hosted by the hypervisor in the secure domain.

17. A computer program product comprising a computer-readable storage medium including computer-executable instructions that, when executed by a security interface control of a processing unit, cause the processing unit to perform a method that includes: Receiving a request to establish shared access to a page of a memory from a security entity of a computer system; Determining whether the page is currently marked as secure by a security storage protection indicator and the page is registered to a security domain of the security entity; Based on determining that the page is marked as secure and is registered to the security domain of the security entity, registering the page to the security domain as shared; Based on the page being marked as insecure by clearing the security storage protection indicator of the page, enabling an insecure entity of the computer system to access a page of the memory shared between the insecure entity and the security domain of the computer system; Before allowing the insecure entity to access the page, verifying that the security storage protection indicator of the page is cleared; and Providing access to the page to the security entity of the security domain without checking the security storage protection indicator of the page.

18. The computer program product of claim 17, wherein the executable instructions further cause the processing unit to perform: Before providing access to the page to the security entity, verifying that a dynamic address translation mapping established by the insecure entity and used by the security entity has not changed.

19. The computer program product according to claim 18, wherein, The executable instructions further cause the processing unit to perform: Based on determining that the page is currently marked as secure, is registered to the security domain of the security entity, and the page is not currently locked, locking the page; And Preventing the security entity or the security interface control in a different context from accessing the page when the page is locked.

20. The computer program product according to claim 19, wherein, The executable instructions further cause the processing unit to perform: When the page is locked, performing one or more authorization checks or status updates of the page; and Based on completing the one or more authorization checks or status updates of the page, unlocking the page.

21. The computer program product according to claim 19, wherein, The executable instructions further cause the processing unit to perform: Based on determining that the page was locked before receiving the request to establish shared access to the page, sending a busy indicator to the security entity.

22. The computer program product according to claim 17, wherein Checking and updating the security domain through a zone security table that includes a security domain identifier associated with the page and virtual address mapping data associated with the page.

Images