Host virtual address space for secure interface control storage

Abstract

According to one or more embodiments of the present invention, a computer-implemented method includes: receiving, at a security interface control of a computer system, a request for access to a data structure associated with a security entity in a security domain of the computer system. The security interface control may examine a virtual storage address associated with a location of the data structure. The security interface control may, based on determining that the location of the data structure is associated with the virtual storage address, request an address translation using a virtual address space of a non-secure entity of the computer system. The security interface control may access the data structure based on a result of the address translation.

Description

Background Art

[0001] The present invention relates generally to computer technology and, more particularly, to using a host virtual address space for secure interface control storage.

[0002] Cloud computing and cloud storage provide users with the ability to store and process their data in third-party data centers. Cloud computing facilitates the ability to quickly and easily provide VMs to customers without the need for customers to purchase hardware or provide floor space for physical servers. Customers can easily expand or shrink VMs according to changes in customer preferences or requirements. Typically, cloud computing providers provide VMs that physically reside on servers at the provider's data center. Customers are often concerned about the security of data in VMs, especially because computing providers typically store data for more than one customer on the same server. Customers may expect security between their own code / data and that of cloud computing providers, as well as security between their own code / data and that of other VMs running at the provider's site. In addition, customers may expect security from the provider's administrators and prevention of potential security breaches from other codes running on the machine.

[0003] To handle such sensitive situations, cloud service providers can implement security controls to ensure proper data isolation and logical storage separation. The widespread use of virtualization in implementing cloud infrastructures 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 it is computing, storage, or even networking hardware. This introduces virtualization as an additional layer that itself must be properly configured, managed, and secured.

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

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

[0006] According to one or more embodiments of the present invention, a computer-implemented method includes receiving, at a security interface control of a computer system, a request for access to a data structure associated with a security entity in a security domain of the computer system. The security interface control may examine a virtual storage address associated with a location of the data structure. The security interface control may, based on determining that the location of the data structure is associated with the virtual storage address, request an address translation using a virtual address space of a non-secure entity of the computer system. The security interface control may access the data structure based on a result of the address translation. Advantages may include providing a host virtual address space for security interface control storage.

[0007] According to additional or alternative embodiments of the present invention, the security interface control may access the data structure using an absolute address based on determining that the location of the data structure is not associated with a virtual storage address. Advantages may include addressing flexibility for absolute addressing.

[0008] According to additional or alternative embodiments of the present invention, a mapping of a virtual storage address provided by a non-secure entity may be verified. Advantages may include checking the integrity of data for a secure entity managed by a non-secure entity.

[0009] According to additional or alternative embodiments of the present invention, verifying the mapping of the virtual storage address may include checking for changes in the mapping compared to a previous mapping. Advantages may include confirming that the non-secure entity has not modified the address mapping for the secure entity.

[0010] According to additional or alternative embodiments of the present invention, data structures associated with security entities in a security domain may be distributed among multiple memory pages. Advantages may include supporting data structure segmentation.

[0011] According to additional or alternative embodiments of the present invention, memory pages donated by a non-secure entity may reside in a contiguous virtual address range. Advantages may include making segmented absolute addresses appear contiguous.

[0012] According to additional or alternative embodiments of the invention, checking the virtual storage address may further include checking a region security table to determine whether virtual address comparison associated with the host virtual address is enabled or disabled.Advantages may include managing addressing mode options by domain or page.

[0013] According to additional or alternative embodiments of the present invention, the security interface control may be firmware, hardware, trusted software, or a combination of firmware, hardware, and trusted software. Advantages may include implementing a security interface control with low impact on the associated operations of overall system performance.

[0014] According to additional or alternative embodiments of the present invention, the non-secure entity may be a hypervisor configured to host one or more secure clients as secure entities. Advantages may include hosting secure clients by a non-secure hypervisor.

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

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

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

[0018] Figure 1 Depicted is a table for zone security according to one or more embodiments of the present invention;

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

[0020] Figure 3 Depicted are nested multi-part DATs supporting virtual machines (VMs) running under a hypervisor in accordance with one or more embodiments of the present invention;

[0021] Figure 4 depicts a mapping of secure client storage according to one or more embodiments of the present invention;

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

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

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

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

[0026] Fig. 9Describes a process for donated memory operations according to one or more embodiments of the present invention;

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

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

[0029] Fig.12 Describes the process flow of access tagging by a security interface control and hardware according to one or more embodiments of the present invention;

[0030] Fig.13 Describes the process flow of conversion performed by a program and a security interface control to support secure and non-secure access according to one or more embodiments of the present invention;

[0031] Fig.14 Describes the processing flow of DAT with secure storage protection by a program and a secure interface control according to one or more embodiments of the present invention;

[0032] Fig.15 depicts a process flow for addressing mode determination according to one or more embodiments of the present invention;

[0033] Fig.16 Depicted is a process flow for using a host virtual address space for secure interface control storage according to one or more embodiments of the present invention;

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

[0035] Fig.18 depicts an abstract model layer according to one or more embodiments of the present invention;

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

[0037] Fig. 20 A processing system in accordance with one or more embodiments of the invention is depicted.

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

[0039] One or more embodiments of the present invention provide additional security using an efficient, lightweight security interface control between software and machines.

[0040] A virtual machine (VM) running as a client under the control of a host hypervisor relies on the hypervisor to transparently provide virtualization services to the client. These services can be applied to any interface between a security entity and another untrusted entity, which traditionally allows the other entity to access secure resources. As previously mentioned, these services may include, but are not limited to, memory management, instruction emulation, and interrupt handling. For example, for interrupts and exception injections, the hypervisor typically reads and / or writes the prefix area (low core) of the client. As used herein, the term "virtual machine" or "VM" refers to a logical representation of a physical machine (computing device, processor, etc.) and its processing environment (operating system (OS), software resources, etc.). VM is maintained as software executed on the underlying host machine (physical processor or processor group). From the perspective of a user or software resource, VM looks like 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 allows multiple VMs to execute using multiple (sometimes different) OSs on the same host. It should be understood that deploying a VM includes the installation process of the VM and the activation (or startup) process of the VM. In another example, deploying the VM includes an activation (or startup) process of the VM (eg, where the VM was previously installed or already exists).

[0041] To facilitate and support secure clients, there are technical challenges as follows: additional security is required between the hypervisor and the secure client without relying on the hypervisor, so that the hypervisor cannot access data from the VM and therefore cannot provide services in the manner described above.

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

[0043] In one example, the security interface control is implemented in internal secure and trusted hardware and / or firmware. The trusted firmware may include, for example, processor millicode or PR / SM logical partition code. For secure clients or entities, the security interface control provides initialization and maintenance of the security environment and coordination of the allocation of these security entities on hardware. When the secure client is actively using data and it resides in the host storage, it is kept as "not at risk" in the secure storage. The secure client storage can be accessed by the single secure client, which is strictly enforced by the hardware. That is, the hardware prevents any non-secure entity (including a hypervisor or other non-secure client) or a different secure client from accessing the data. In this example, the security interface control runs as a trusted portion of the lowest level firmware. The lowest level or millicode is actually an extension of the hardware and is used to implement, for example, The millicode has access to all memory sections, which, in the context of secure execution, includes its own secure UV storage, non-secure hypervisor storage, secure client storage, and shared storage. This allows it to provide any functionality required by a secure client or the hypervisor supporting that client. The security interface control also has direct access to the hardware, which allows the hardware to effectively provide security checks under the control of the conditions established by the security interface control.

[0044] According to one or more embodiments of the present invention, a secure storage bit is provided in hardware to mark a secure page. When this bit is set, the hardware prevents any non-secure client or hypervisor from accessing the page. In addition, each secure page or shared page is registered in the regional security table and marked with a secure client domain identifier (ID). When a page is non-secure, it is so marked in the regional security table. The regional security table is maintained by the security interface control of each partition or region. Each host absolute page has an entry, which is used by hardware in any DAT conversion performed by a secure entity to verify that the page is only accessed by the secure client or entity that owns it.

[0045] According to one or more embodiments of the present invention, the security interface control has its own secure UV storage, which can only be accessed by the security interface control itself. This storage is used by the security interface control and hardware to provide the required security to the security client. The security interface control uses this secure storage to store information about itself, the area enabled to run the security client, the security client, and the security virtual CPU. Similar to the security client storage, the security interface control storage is also marked as a secure page to prevent access by any non-security entity. In addition, the security interface control storage has its own security domain ID, which is used to prevent any other security entity from accessing the security interface control storage.

[0046] One or more embodiments of the present invention use the host virtual address space for secure interface control storage. The memory area for storing information about the secure interface control, the client, and the virtual CPU is usually located in absolute memory, which means that the secure interface control can directly access the memory area without address translation. In order to allow secure swapping, data structures such as integrity tables can be created, maintained, and used in the memory area donated from the host to the secure interface control. The integrity table can save the checksum of the content and related information of each page when the page is swapped out to the disk, so that once the page is swapped back, the content of the page can be checked. The size of the integrity table can depend on the size of the storage of the secure client and can span large memory areas. The integrity table and other data structures of the secure interface control can be allocated at runtime and may need to be represented as continuous memory for each data structure. Once the system has been running for a period of time, it may become challenging to find a large continuous storage area due to memory segmentation. One or more embodiments of the present invention provide a workaround for the memory segmentation problem by allowing large continuous storage areas to be allocated to the secure interface control even when the system has been running for a period of time. Rather than limiting the secure interface control to address memory as absolute addresses, the secure interface control may use virtual storage in the address space of the untrusted hypervisor to store one or more data structures, such as integrity tables. This may enable the secure interface control to use dynamic address translation (DAT) to access structures in the host virtual address space for the secure interface control to store.

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

[0048] These UVC commands can be executed by the machine firmware similarly to many other architecture instructions. The machine does not enter the secure interface control mode, but the machine performs the secure interface control functions in the mode in which it is currently running. The hardware maintains both the firmware state and the software state, so there is no context switching to process these operations. This low overhead allows for tightly coupled collaboration between the different layers of software, trusted firmware, and hardware in a way that minimizes and reduces the complexity of the secure interface control while still providing the necessary level of security.

[0049] According to one or more embodiments of the present invention, in order to support the control block structures required by the security interface control and hardware to properly maintain the secure client and support the hypervisor environment, the hypervisor donates storage to the security interface control when initializing the secure client environment. As a result, in order to prepare 1) to initialize the area to run the secure client, 2) to create the secure client domain, and 3) to create the secure CPU running in each domain, the hypervisor issues a query UVC instruction to determine the amount of storage required for donation. Once the storage has been donated, it is marked as secure and registered as belonging to the security interface control; and access by any non-secure or secure client entity is prohibited. This remains the case until the associated entity (e.g., secure client CPU, secure client domain or area) is destroyed.

[0050] In one example, the first section of UV storage for supporting region-specific UV control blocks is donated to the security interface control as part of initializing UVC and resides in what is referred to herein as UV2 storage. The second and third sections of UV storage for supporting basic and variable secure client configuration control blocks (for each secure client domain) are donated as part of creating a secure client configuration UVC and reside in UVS storage and UVV storage, respectively. The fourth and last sections of UV storage for supporting secure CPU control blocks also reside in the UVS space and are donated as part of creating a secure client CPU UVC. When each of these regions is donated, the security control interface marks them as secure (to prevent them from being accessed by any non-secure entity) and also registers them in the regional security table as belonging to the security interface control (to prevent them from being accessed by any secure client entity). In order to provide further isolation within the UV space, the UV2 space (which is not associated with any specific secure client domain) is also marked with a unique UV2 security domain, while both the UVS and UVV spaces are further marked with associated specific secure client domains. In this example, the UVV space resides in the host virtual space and thus can be further identified with a host virtual to host absolute mapping.

[0051] Although the security interface control can access all storage (non-secure storage, secure client storage, and UV storage), one or more embodiments of the present invention very specifically provide mechanisms that allow the security interface control to access UV storage. Using the same hardware mechanism that provides isolation between secure client domains, embodiments of the present invention can provide similar isolation within UV storage. This ensures that the security interface control only accesses UV storage when expected and specified; only accesses secure client storage for the specified desired secure client; and only accesses non-secure storage when specified. That is, the security interface control can very clearly specify the storage it intends to access so that the hardware can ensure that it does access the storage. In addition, it can also specify that it only intends to access UV storage associated with the specified secure client domain.

[0052] To provide security, the security interface control working with the hardware provides and guarantees decryption and encryption of data when the hypervisor transparently pages secure client data in and out. To achieve this, the hypervisor is required to issue new UVCs when paging in and out client secure data. Based on the controls established by the security interface control during these new UVCs, the hardware will guarantee that these UVCs are indeed issued by the hypervisor.

[0053] In this new security environment, every time the hypervisor pages out a secure page, a new transition from secure storage (export) UVC needs to be issued. In response to the export UVC, the security interface control will: 1) indicate that the page is UV "locked", 2) encrypt the page, 3) set the page to non-secure, and 4) reset the UV lock. Once the export UVC is completed, the hypervisor can immediately page out the encrypted client page.

[0054] In addition, each time the hypervisor pages in a secure page, it must issue a new translation to the secure storage (import) UVC. In response to the import UVC, the UV or security interface control will: 1) mark the page as secure in hardware, 2) indicate that the page is "locked" by the UV, 3) decrypt the page, 4) set the permissions to a specific secure client domain, and 5) reset the UV lock. Whenever an access is made by a secure entity, the hardware performs authorization checks on the page during the translation. These checks include: 1) a check to verify that the page does belong to the secure client domain that is attempting to access it, and 2) a check to ensure that the hypervisor has not changed the host mapping of the page while the page is already resident in client memory. Once a page is marked as secure, the hardware prevents the hypervisor or non-secure client VM from accessing any secure page. The additional translation step prevents access by another secure VM and prevents remapping by the hypervisor.

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

[0056] Furthermore, if Figure 1 As shown, the region security table 100 includes a security domain ID 120 (which identifies the security domain associated with the page); a UV bit 130 (which indicates that the page is donated to and owned by the security interface control); a disable address comparison (DA) bit 140 (used to disable host address pair comparisons in situations 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 (which indicates that the page is shared with a non-secure hypervisor) and a host virtual address 160 (which indicates the host virtual address registered for the host absolute address, which is referred to as a host address pair). Note that the host address pair indicates a host absolute address and an associated registered host virtual address. The host address pair represents the mapping of the page, once imported by the hypervisor, and the comparison ensures that the host has not remapped the page while it is being used by the client.

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

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

[0059] DAT uses a multi-table lookup to convert a virtual address into an associated absolute address. This table structure is typically defined and maintained by a storage manager. The storage manager transparently shares absolute storage between multiple programs by paging out a page to, for example, bring in another page. For example, when a page is paged out, the storage manager will set an invalid bit in the associated page table. When a program attempts to access a page that has been paged out, the hardware will submit a program interrupt, commonly referred to as a page fault, to the storage manager. 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 it between various different users.

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

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

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

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

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

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

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

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

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

[0069] 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 does belong to that particular secure client. If not, a non-secure access (PIC3E) exception is submitted to the hypervisor. Additionally, if the host virtual address being translated does not match the host virtual address from a registered host address pair in the zone security table, a secure storage violation ('3F'x) exception is identified. To enable sharing with the hypervisor, a secure client can access storage that is not marked as secure as long as the translation check allows access.

[0070] Now go to Figure 5 , generally illustrates a system diagram 500 of DAT operations according to one or more embodiments of the present invention. System diagram 500 includes a host primary virtual address space 510 and a host home virtual address space 520, from which pages are translated (e.g., see host DAT translation 525; note that the dashed lines represent mappings through DAT translation 525) to a hypervisor (host) absolute address space 530. For example, Figure 5 Shown is sharing of host absolute storage by two different host virtual address spaces and one of those host virtual addresses not only between two clients but also with the host itself. At this point, host primary virtual address space 510 and host home virtual address space 520 are examples of two types of host virtual address spaces, each of which is addressed by a separate ASCE (host primary ASCE (HPASCE) 591) and host home ASCE (HHASCE) 592, respectively. Note that all security interface control storage (both virtual and real) is donated by the hypervisor and marked as secure. Once donated, the security interface control storage can only be accessed by the security interface control as long as there is an associated security entity.

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

[0072] According to one or more embodiments of the present invention, all secure clients (e.g., secure client A and secure client B) are stored in the regional security table described herein and are registered as belonging to the secure client 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 client storage is mapped in the host main virtual space. In addition, all secure interface control storage is also registered in the regional security table as belonging to the secure interface control, and can be further distinguished in the regional security table based on the associated secure client domain. According to one or more embodiments of the present invention, UV virtual storage is mapped in the host belonging virtual space, and the associated host virtual address is registered as part of the host address pair. According to one or more embodiments, UV actual storage does not have an associated host virtual mapping, and the DA bit in the regional security table (which indicates that the virtual address comparison is disabled) is set to indicate this. The host storage is marked as non-secure and is also registered as non-secure in the regional security table.

[0073] Therefore, 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: client A absolute page A1.HV is mapped to host absolute A1.HA belonging to secure client A; client A absolute page A2.HV is mapped to host absolute A2.HA belonging to secure client A; client B absolute page B1.HV is mapped to host absolute B1.HA belonging to secure client B; and host virtual page H3.HV is mapped to host absolute page H3.HA non-secure host (and since it is not secure, there is no host address pair). Further, the hypervisor (host) home DAT table (defined by HHASCE 592) converts pages of the host home virtual address space 520 as follows: secure interface control virtual page U1.HV is mapped to host absolute page U1.HA defined as secure UV virtual; host virtual page H1.HV is mapped to host absolute page H1.HA defined as non-secure; and host virtual page H2.HV is mapped to host absolute page H2.HA defined as non-secure. Since H1.HA or H2.HA is non-secure, there is no host-address pair associated with H1.HA or H2.HA.

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

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

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

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

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

[0079] Now turn to Figure 8 , generally illustrating a process flow 800 for performing an import operation according to one or more embodiments of the present invention. In response to 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 point, the page to be imported is marked as non-secure and can only be accessed by the hypervisor, other non-secure entities, and secure interface controls. It cannot be accessed by secure clients.

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

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

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

[0083] At block 855, the security interface control unlocks the page, allowing other UVC access, and registers the page as secure in the region security table and associates it with the appropriate client domain and host virtual address to complete the host address HV→HA pair. This allows client access and completes the UVC.

[0084] Now turn to Fig. 9 , generally illustrates a process flow 900 for donated memory operations according to one or more embodiments of the present invention. Process flow 900 begins at block 905, where the hypervisor issues a query UVC to the security interface control. At block 910, the security interface control returns data (e.g., the query UVC). The data may include: a basic region-specific host absolute storage amount required; a basic secure client domain-specific host absolute storage amount required; a variable secure client domain-specific host virtual storage amount required per MB; and / or a basic secure client CPU-specific host absolute storage amount required.

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

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

[0087] At box 930, the hypervisor reserves storage (e.g., base and variable secure client domain specific storage). For example, the hypervisor reserves base and variable (e.g., based on the size of the secure client domain storage) secure client domain specific storage (e.g., the size returned by the query UVC). At box 935, the hypervisor issues a create configuration to the secure interface control. At this point, the hypervisor may issue a create secure client configuration UVC specifying the base and variable secure client domain specific storage origins. Further, the create secure client configuration UVC provides donated storage for UV control blocks required to support the secure client configuration.

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

[0089] At box 945, the hypervisor reserves the base secure client CPU specific storage (e.g., the size returned by the query UV). At box 950, the hypervisor specifies the storage origin. For example, the hypervisor issues a create secure client CPU to the UV specifying the base secure client CPU specific storage origin. At box 955, the security interface control implements the create CPU (e.g., create secure client CPU UVC). For the create secure client CPU UVC, the security interface control may mark the donated storage as secure and register the donated storage in the regional security table for UV use, but not to the associated secure client domain and registered as having no associated host virtual address pair.

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

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

[0092] At arrow 1025, a Create SG Configuration or Create SG CPU UVC is issued from the hypervisor (non-secure) page B, which transfers the page to the secure interface control real storage 1030 associated with the secure client domain (UVS). The secure interface control real storage 1030 may be marked as secure and in the region security table (e.g., Figure 1 The UVs are registered in the region security table 100 as having an associated secure client domain and no hypervisor to host absolute (HV→HA) mapping (i.e., DA bit = 1) as having an associated secure client domain. Note that the secure interface control actual storage 1010 is accessible to the secure interface control as representing the secure client domain.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0106] Now go to Fig.15 , generally illustrates a process flow 1500 for addressing mode determination according to one or more embodiments of the present invention. Fig.10 As described, the security interface control can access a page, such as page B in UVS, which has been established as actual / absolute storage accessible through the security interface control actual storage 1030. Further, the security interface control can access a page, such as page C in UVV, which is in Fig.10 In the processing flow 1000, a virtual storage 1050 has been established as a secure interface control. Fig.11The process flow 1100 may determine at block 1130 whether an access to the UVV space should be performed (such as for the completeness table), or at block 1150 whether an access to the UVS space should be performed. The process flow 1500 further illustrates that it may support Fig.11 The address conversion process of the processing flow 1100 is as follows. Fig.15 In block 1505, when the security interface control needs to access one or more data structures associated with the security client (such as Figure 1 100 ), the process flow 1500 proceeds to block 1510. At block 1510, the security interface control may determine whether the access is associated with a virtual storage address. At block 1515, if the access is associated with a virtual storage address, the security interface control may use the virtual address space of the hypervisor to translate the virtual storage address, such as through the DAT table. At block 1520, the security interface control and / or supporting hardware / firmware may perform one or more checks to ensure that the expected mapping of the virtual storage address (e.g., the mapping previously registered for the absolute page) is returned from the access through the hypervisor DAT. As an example, the security interface control may confirm that the hypervisor has not changed the associated host mapping of the data structure as previously configured. At block 1525, once the absolute address has been determined through the hypervisor's DAT table, or if the access has been associated with an absolute address (e.g., block 1510=No), the security interface control may access the data structure at the absolute address.

[0107] Now turn to Fig.16 , generally illustrates a process flow 1600 for secure interface control storage using a host virtual address space according to one or more embodiments of the present invention. The process flow 1600 is Fig.15 A variation of processing flow 1500 of . At box 1605, a security interface control of a computer system may receive an access request to a data structure associated with a security entity in a security domain of the computer system. The access request may be part of an internal sequence for managing security through the security interface control. The security entity may be one or more secure clients, such as a VM or a secure container. At box 1610, the security interface control may check a virtual storage address associated with the location of the data structure. The data structure associated with the security entity in the security domain may be distributed among multiple memory pages. Memory pages may be donated by non-secure entities at multiple fixed locations for secure use by the security interface control. Memory pages donated by non-secure entities may reside at a continuous virtual address range. The non-secure entity may be a hypervisor or operating system configured to host one or more secure clients or containers as security entities. Checking the virtual storage address mapping may include checking Figure 1The region security table 100 is used to determine whether virtual address comparison associated with the host virtual address is enabled or disabled (eg, the DA bit 140 state).

[0108] At box 1615, the security interface control can be associated with the virtual storage address based on the location of the data structure, using the virtual address space of the non-safe entity of the computer system to perform address translation. Any process and element previously described can be used to perform address translation. The mapping of the virtual storage address provided by the non-safe entity can be verified by the security interface control. The verification of the mapping of the virtual storage address can include checking the change of the mapping compared to the previously registered mapping. The mapping by the address translation table can be configured to present the memory pages distributed in the non-continuous absolute position as continuous virtual addresses. Therefore, the data structure that cannot fit into the continuous absolute memory block can be shown as continuous in the virtual address space of the host.

[0109] At block 1620, the secure interface control may access the data structure based on the absolute address obtained from the address translation. Alternatively, the secure interface control may directly access the data structure using the absolute address based on determining that the location of the data structure is not associated with a virtual storage address.

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

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

[0112] Features are as follows:

[0113] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capacity (such as server time and network storage) on demand without manual interaction with the service provider.

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

[0115] Resource pooling: The computing resources of a provider are grouped into resource pools to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Generally, consumers cannot control or know the exact location of the provided resources, but can specify the location at a higher level of abstraction (such as country, state, or data center), thus having location independence.

[0116] Rapid elasticity: Capacity can be rapidly and elastically (in some cases automatically) provisioned to scale out quickly and released quickly to scale down quickly. To the consumer, the capacity available for provisioning often appears to be unlimited and can be purchased in any quantity at any time.

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

[0118] The service model is as follows:

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

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

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

[0122] The deployment model is as follows:

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

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

[0125] Public cloud: Cloud infrastructure is available to the general public or large industry groups and is owned by an organization that sells cloud services.

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

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

[0128] Reference now Fig.17 , describes an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks (such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above). This allows the cloud computing environment 50 to provide infrastructure as a service, platform as a service, and / or software as a service without the cloud consumer having to maintain resources for them on a local computing device. It should be understood that Fig.17 The various types of computing devices 54A-N shown in the figure are merely illustrative, and the computing node 10 and cloud computing environment 50 can communicate with any type of computing device over any type of network and / or network addressable connection (eg, using a web browser).

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

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

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

[0132] In one example, the management layer 80 may provide the functionality described below. Resource provisioning functionality 81 provides dynamic acquisition of computing resources and other resources for performing tasks in a cloud computing environment. Metering and pricing functionality 82 provides cost tracking of resources used within the cloud computing environment and provides bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security functionality provides identity authentication for cloud consumers and tasks and provides protection for data and other resources. User portal functionality 83 provides access to the cloud computing environment for consumers and system administrators. Service level management functionality 84 provides allocation and management of cloud computing resources to meet required service levels. Service level agreement (SLA) planning and fulfillment functionality 85 provides pre-scheduling and procurement of cloud computing resources for which future demand is predicted in accordance with the SLA.

[0133] The workload layer 90 provides examples of functions that can utilize a cloud computing environment. In this layer, examples of workloads and functions that can be provided include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom teaching provision 93; data analysis processing 94; transaction processing 95; and controlling access to secure storage associated with virtual machines 96. It will be understood that these are just some examples, and in other embodiments, these layers may include different services.

[0134] Now turn to Fig.19, depicting a system 1900 according to one or more embodiments of the present invention. The system 1900 includes an example node 10 (e.g., a hosting node) that communicates directly or indirectly with one or more client devices 20A-20E, for example, via a network 165. The node 10 may be a data center or host server of a cloud computing provider. The node 10 executes a hypervisor 12 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 to provide one or more services to the virtual machines 15. There may be communication between: the hypervisor 12 and the security interface control 11; the security interface control 11 and one or more VMs 15; the hypervisor 12 and one or more VMs 15; and from the hypervisor 12 to the VM 15 through the security interface control 11. To facilitate a secure VM environment, the hosting node 10 according to one or more embodiments of the present invention does not include any direct communication between the hypervisor 12 and the one or more VMs 15.

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

[0136] In one example, client devices 20A-20E may belong to the same entity, such as an individual, an enterprise, a government agency, a department within a company, or any other entity, and node 10 may operate as a private cloud for that entity. In this case, node 10 individually hosts VMs 15A-15N deployed by client devices 20A-20E belonging to that entity. In another example, client devices 20A-20E may belong to different entities. For example, a first entity may own client device 20A, while a second entity may own client device 20B. In this case, node 10 may operate as a public cloud that hosts VMs from different entities. For example, VMs 15A-15N may be deployed in a shielded manner in which VM 15A does not have easy access to VM 15B. For example, node 10 may use The processor resource / system manager (PR / SM) logical partition (LPAR) features are used to shield the VMs 15A-15N. Therefore, these features (e.g., PR / SM LPAR provides isolation between partitions) facilitate the node 10 to deploy two or more VMs 15A-15N in different logical partitions for different entities on the same physical node 10. The PR / SM LPAR hypervisor is implemented in a trusted internal firmware with specific hardware to provide such isolation.

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

[0138] Now go to Fig. 20 , a node 10 for implementing the teachings herein according to one or more embodiments of the present invention is shown. The node 10 may be an electronic computer architecture that includes and / or employs any number of computing devices and combinations of computing devices and networks utilizing various communication technologies, as described herein. The node 10 may be easily scalable, extensible, and modular, capable of being changed into different services or reconfiguring some features independently.

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

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

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

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

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

[0144] Embodiments of the invention disclosed herein may include systems, methods and / or computer program products (herein systems) for controlling access to secure storage of a VM. Note that for each illustration, the identifiers of elements are repeated for other similar elements of different drawings.

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

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

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

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

[0149] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include (one or more) computer-readable storage media having computer-readable program instructions thereon, and the computer-readable program instructions are used to cause a processor to perform various aspects of the present invention.

[0150] Computer readable storage medium can be a tangible device that can hold and store instructions used by an instruction execution device. Computer readable storage medium can be, for example, but not limited to, any suitable combination of electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or the aforementioned storage devices. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, such as a punch card or a convex structure in a groove with instructions recorded on it, and any suitable combination of the above devices. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses by optical fiber cables), or electrical signals transmitted by wires.

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

[0152] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of integrated circuits, 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 process programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit, so as to perform various aspects of the present invention.

[0153] Various aspects of the present invention are described herein with reference to the flow chart and / or block diagram of the method, device (system) and computer program product according to embodiments of the present invention. It will be understood that each frame of the flow chart and / or block diagram and the combination of frames in the flow chart and / or block diagram can be implemented by computer-readable program instructions.

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

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

[0156] Flowchart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in the flow chart or block diagram can represent the module, segment or part of instruction, which includes one or more executable instructions for realizing the specified logical function.In some alternative embodiments, the function noted in the frame may not occur in the order noted in the figure.For example, two frames shown continuously can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of the frames in each frame of the block diagram and / or flow chart illustration and the block diagram and / or flow chart illustration can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0157] The terms used herein are only for the purpose of describing specific embodiments and are 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 also be understood that the terms "comprises" and / or "comprising" when used in this specification specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, element components, and / or groups thereof.

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

Claims

1. A method for secure interface control storage, comprising: Receiving, at a security interface control of a computer system, a request for access to a data structure associated with a security entity in a security domain of the computer system, wherein the security interface control comprises firmware, hardware, trusted software, or a combination of firmware, hardware, and trusted software; checking, by the security interface control, a virtual storage address associated with the location of the data structure, wherein checking the virtual storage address further comprises: checking a region security table to determine whether a virtual address comparison associated with the host virtual address is enabled or disabled, wherein the region security table includes an entry for each page of host absolute storage, each entry being indexed by a host absolute address, and each entry including information for verifying that the entry belongs to a security entity; verifying, by the security interface control based on determining that the virtual address comparison indication is enabled, a mapping of the virtual storage address provided by the non-secure entity; requesting, by the secure interface control, an address translation using a virtual address space of the non-secure entity of the computer system based on determining that the location of the data structure is associated with the virtual storage address; and The data structure is accessed by the secure interface control based on a result of the address translation.

2. The method according to claim 1, further comprising: The data structure is accessed using an absolute address by the secure interface control based on determining that the location of the data structure is not associated with the virtual storage address.

3. The method according to claim 1, wherein: Verifying the mapping of the virtual storage address includes checking the mapping for changes compared to a previous mapping.

4. The method according to any one of claims 1 to 3, wherein: The data structures associated with the security entities in the security domain are distributed among a plurality of memory pages.

5. The method according to claim 4, wherein: The memory pages donated by the non-secure entity reside in a contiguous virtual address range.

6. The method according to any one of claims 1 to 3, wherein: The non-secure entity includes a hypervisor configured to host one or more secure clients as the secure entity.

7. A computer system comprising: Memory; Processing unit; as well as The security interface control is configured to perform a plurality of operations, the plurality of operations comprising: Receiving a request for access to a data structure associated with a security entity in a security domain, wherein the security interface control comprises firmware, hardware, trusted software, or a combination of firmware, hardware, and trusted software; checking a virtual storage address associated with the location of the data structure in the memory, wherein checking the virtual storage address further comprises: checking a zone security table to determine whether virtual address comparison associated with the host virtual address is enabled or disabled, wherein the zone security table includes an entry for each page of host absolute storage, each entry being indexed by a host absolute address, and each entry including information for verifying that the entry belongs to a secure entity; verifying a mapping of the virtual storage address provided by the non-secure entity based on determining that a virtual address comparison indication is enabled; based on determining that the location of the data structure is associated with the virtual storage address, requesting an address translation using a virtual address space of the non-secure entity of the processing unit; and The data structure is accessed based on a result of the address translation.

8. The computer system according to claim 7, wherein: The security interface control is configured to perform operations including: Based on determining that the location of the data structure is not associated with the virtual storage address, the data structure is accessed using an absolute address.

9. The system according to claim 7, wherein: Verifying the mapping of the virtual storage address includes checking the mapping for changes compared to a previous mapping.

10. The system according to any one of claims 7 to 9, wherein: The data structures associated with the security entities in the security domain are distributed among a plurality of pages of the memory.

11. The system according to claim 10, wherein: The pages of the memory donated by the non-secure entity reside in a contiguous virtual address range.

12. A system according to any one of claims 7 to 9, wherein: The non-secure entity includes a hypervisor configured to host one or more secure clients as the secure entity.

13. A computer program product comprising a computer-readable storage medium, the computer-readable storage medium comprising computer-executable instructions which, when executed by a security interface control of a processing unit, cause the processing unit to perform a method comprising: receiving, at the security interface control, a request for access to a data structure associated with a security entity in a security domain, wherein the security interface control comprises firmware, hardware, trusted software, or a combination of firmware, hardware, and trusted software; checking, by the security interface control, a virtual storage address associated with the location of the data structure, wherein checking the virtual storage address further comprises: checking a region security table to determine whether a virtual address comparison associated with the host virtual address is enabled or disabled, wherein the region security table includes an entry for each page of host absolute storage, each entry being indexed by a host absolute address, and each entry including information for verifying that the entry belongs to a security entity; verifying, by the secure interface control, a mapping of the virtual storage address provided by the non-secure entity based on determining that a virtual address comparison indication is enabled; requesting, by the secure interface control, an address translation using a virtual address space of the non-secure entity based on determining that the location of the data structure is associated with the virtual storage address; and The data structure is accessed by the secure interface control based on a result of the address translation.

14. The computer program product of claim 13, wherein: The executable instructions further cause the processing unit to execute: The data structure is accessed using an absolute address by the secure interface control based on determining that the location of the data structure is not associated with the virtual storage address.

15. The computer program product of claim 13, wherein: Verifying the mapping of the virtual address includes checking the mapping for changes compared to a previous mapping.

16. A computer program product according to any one of claims 13 to 15, wherein: The data structures associated with the security entities in the security domain are distributed among a plurality of memory pages.

17. The computer program product of claim 16, wherein: The memory pages donated by the non-secure entity reside in a contiguous virtual address range.

Images