阅读说明：本技术 安全接口控件高级页管理 (Security interface control advanced page management ) 是由 M·施维德夫斯基 H·卡斯滕斯 J·布拉德伯里 L·海勒 于 2020-03-06 设计创作，主要内容包括：提供了一种方法。该方法由计算机的防止未经授权访问计算机的内存中的位置的安全接口控件来实现。安全接口控件确定机绝对页先前未按照保护主机绝对页被映射到虚拟页并且主机虚拟页尚未按照保护主机绝对页被映射到绝对页。(A method is provided. The method is implemented by a secure interface control of a computer that prevents unauthorized access to a location in a memory of the computer. The security interface control determines that the machine absolute page has not previously been mapped to a virtual page as a protected host absolute page and that the host virtual page has not been mapped to an absolute page as a protected host absolute page.)

1.A method, comprising:

determining, by a security interface control of a computer that prevents unauthorized access to a location in a memory of the computer, that a host absolute page has not previously been mapped to a virtual page according to a protected host absolute page; and

determining, by the security interface control, that the host virtual page has not been mapped to the absolute page as a protected host absolute page.

2. The method of claim 1, wherein the secure interface control marks a host absolute page as secure.

3. The method of any preceding claim, wherein the secure interface control registers the host absolute page for use by the secure interface control, securely decrypts the host absolute page, then unregisters the host absolute page for use by the secure interface control, and registers the host absolute page to the secure domain.

4. The method of any preceding claim, wherein the secure interface control registers a host virtual address with an associated host absolute page to create a host-address pair for use by the secure entity, and checks for a host virtual address match when accessed by the secure entity.

5. The method of any preceding claim, wherein the secure interface control locks the host absolute page for use by the secure interface control to prevent further calls to the host absolute page.

6. The method of any of the preceding claims, wherein the secure interface control unlocks a host absolute page to allocate a secure guest domain loaded into memory.

7. The method of any preceding claim, wherein the secure entity accesses secure pages that are transparently paged in by an untrusted entity executing on the computer and that are non-secure.

8. The method of claim 7, wherein the untrusted entity is a virtual machine monitor, and wherein the secure entity is a secure client.

9. A method according to claim 7 or 8, wherein the hardware submits a program interrupt to the untrusted entity indicating a need to decrypt the secure guest page.

10. The method of any of claims 7 to 9, wherein the untrusted entity issues an import instruction that provides a host absolute page and a host virtual page.

11. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable to cause operations comprising:

determining, by a security interface control of a computer that prevents unauthorized access to a location in a memory of the computer, that a host absolute page has not previously been mapped to a virtual page according to a protected host absolute page; and

determining, by the security interface control, that the host virtual page has not been mapped to the absolute page as a protected host absolute page.

12. The computer program product of claim 11, wherein the secure interface control marks a host absolute page as secure.

13. The computer program product of claim 11 or 12, wherein the secure interface control registers the host absolute page for use by the secure interface control, securely decrypts the host absolute page, subsequently unregisters the host absolute page for use by the secure interface control, and registers the host absolute page to the secure domain.

14. The computer program product of any of claims 11 to 13, wherein the secure interface control registers the host virtual address with an associated host absolute page to create a host-address pair for use by the secure entity and checks for a host virtual address match when accessed by the secure entity.

15. The computer program product of any of claims 11 to 14, wherein the secure interface control locks the host absolute page for use by the secure interface control to prevent further calls to the host absolute page.

16. The computer program product of any of claims 11 to 15, wherein the secure interface control unlocks a host absolute page to allocate a secure guest domain loaded into memory.

17. The computer program product of any of claims 11 to 16, wherein the secure entity accesses secure pages that are transparently paged in by an untrusted entity executing on the computer and that are non-secure.

18. The computer program product of claim 17, wherein the untrusted entity is a virtual machine monitor, and wherein the secure entity is a secure client.

19. A computer program product according to claim 17 or 18, wherein the hardware submits a program interrupt to the untrusted entity indicating a need to decrypt the secure guest page.

20. The computer program product of any of claims 17 to 19, wherein the untrusted entity issues an import instruction that provides a host absolute page and a host virtual page.

21. A system, comprising:

a memory;

a secure interface control of the system that prevents unauthorized access to locations in memory,

wherein the system performs operations comprising:

determining, by a security interface control of a computer that prevents unauthorized access to a location in a memory of the computer, that a host absolute page has not previously been mapped to a virtual page according to a protected host absolute page; and

determining, by the security interface control, that the host virtual page has not been mapped to the absolute page as a protected host absolute page.

22. The system of claim 21, wherein the secure interface control marks a host absolute page as secure.

23. The system of claim 21 or 22, wherein the secure interface control registers the host absolute page for use by the secure interface control, securely decrypts the host absolute page, subsequently unregisters the host absolute page for use by the secure interface control, and registers the host absolute page to the secure domain.

24. The system of any of claims 21 to 23, wherein the secure interface control registers the host virtual address with an associated host absolute page to create a host-address pair for use by the secure entity, and checks for a host virtual address match when accessed by the secure entity.

25. The system of any of claims 21 to 24, wherein the secure interface control locks the host absolute page for use by the secure interface control to prevent further calls to the host absolute page.

Background

The present invention relates generally to computer technology and more particularly to secure interface control advanced page management.

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 provision Virtual Machines (VMs) to clients without requiring the clients to purchase hardware or provide ground space for physical servers. The client can easily expand or contract the VM according to the client's changing preferences or requirements. Typically, cloud computing providers provide VMs that physically reside on servers at the provider's data center. The client is often concerned with the security of the data in the VM, particularly because the computing provider typically stores data for more than one client on the same server. The clients may desire security between their own code/data and the code/data of the cloud computing provider, as well as between their own code/data and the code/data of other VMs running at the provider's site. Further, the customer may desire security from the provider's administrator as well as prevent potential security breaches from other code running on the machine.

To handle such sensitive situations, the cloud service provider may implement security controls to ensure proper data isolation and logical storage isolation. The widespread use of virtualization in implementing cloud infrastructures leads to unique security concerns for cloud service customers, as virtualization changes the relationship between the Operating System (OS) and the underlying hardware, whether computing, storage, or even networking hardware. This introduces virtualization as an additional layer that itself must be properly configured, managed, and protected.

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

In the case of memory management, a VM may move its data out of disk (page-in) to reside in memory, and may also move its data back to disk (page-out). When a page resides in memory, a VM (guest) uses Dynamic Address Translation (DAT) to map the memory page from a guest virtual address (virtual address) to a guest absolute address (absolute address). In addition, the host virtual machine monitor has its own DAT mapping (from host virtual address to host absolute address) for guest memory pages (guest pages in memory), and it can page guest pages (guest pages) into and out of memory independently and transparently to the guest. It is through the host DAT table that the virtual machine monitor provides memory isolation or sharing between two separate guest VMs present within a guest. The host can also access the guest memory on behalf of the guest as necessary to simulate guest operation.

Disclosure of Invention

In accordance with one or more embodiments, a method is provided. The method is implemented by a secure interface control of the computer that prevents unauthorized access to locations in the memory of the computer. The secure interface control determines that the host absolute page has not previously been mapped to a virtual page as a protected host absolute page and that the host virtual page has not been mapped to an absolute page as a protected host absolute page. Technical effects and benefits of one or more embodiments of the invention herein may include prohibiting access to secure storage by all non-secure clients and virtual machine monitors.

In accordance with one or more embodiments or the above-described method embodiments, the secure interface control may mark the host absolute page as secure.

In accordance with one or more embodiments or any of the method embodiments described above, the security interface control can register the host absolute page for use by the security interface control, securely decrypt the host absolute page, then unregister the host absolute page for use by the security interface control, and register the host absolute page to the security domain.

In accordance with one or more embodiments or any of the method embodiments described above, the secure interface control can register a host virtual address with an associated host absolute page to create a host-address pair for use by the secure entity, and check for a host virtual address match when accessed by the secure entity.

In accordance with one or more embodiments or any of the method embodiments described above, the security interface control can lock the host absolute page for use by the security interface control to prevent further calls to the host absolute page. Technical effects and benefits of one or more embodiments of the invention described herein may include ensuring that storage is not shared between secure clients because storage is shared between a single secure client and a virtual machine monitor under control of the secure client.

In accordance with one or more embodiments or any of the method embodiments described above, the secure interface control may unlock host absolute pages to allocate a secure guest domain loaded into memory. Technical effects and benefits of one or more embodiments of the invention described herein may include ensuring that storage is not shared between secure clients because storage is shared between a single secure client and a virtual machine monitor under control of the secure client.

In accordance with one or more embodiments or any of the above method embodiments, a secure entity may access secure pages that are transparently paged in by an untrusted entity executing on a computer and that are non-secure

In accordance with one or more embodiments or any of the method embodiments described above, the untrusted entity may be a virtual machine monitor and the secure entity may be a secure client. Technical effects and benefits of one or more embodiments of the invention described herein may include a virtual machine monitor ensuring that, for any given resident secure guest page, an associated host absolute address is accessible only through a single virtual machine monitor (host) DAT mapping.

In accordance with one or more embodiments or any of the method embodiments described above, the hardware submits a program interrupt to the untrusted entity indicating a need to decrypt the secure guest page.

In accordance with one or more embodiments or any of the method embodiments described above, the untrusted entity may issue an import instruction that provides a host absolute page and a host virtual page.

The method can be implemented as a computer program product and/or system in accordance with one or more embodiments or any of the method embodiments described above.

Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.

Drawings

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

FIG. 1 depicts a partition security table in accordance with one or more embodiments of the invention;

FIG. 2 depicts a virtual address space and an absolute address space for executing DAT in accordance with one or more embodiments of the invention;

FIG. 3 depicts a nested multipart DAT for supporting Virtual Machines (VMs) running under a virtual machine monitor in accordance with one or more embodiments of the present invention;

FIG. 4 depicts a mapping of secure client storage in accordance with one or more embodiments of the invention;

FIG. 5 depicts a system diagram of a Dynamic Address Translation (DAT) operation in accordance with one or more embodiments of the invention;

FIG. 6 depicts a system diagram of a secure interface control memory in accordance with one or more embodiments of the invention;

FIG. 7 depicts a process flow of an import operation in accordance with one or more embodiments of the invention;

FIG. 8 depicts a process flow of an import operation in accordance with one or more embodiments of the invention;

FIG. 9 depicts a process for donated memory operations in accordance with one or more embodiments of the invention;

FIG. 10 depicts a process flow of converting a non-secure virtual machine monitor page to a secure page of a secure interface control in accordance with one or more embodiments of the invention;

FIG. 11 depicts a process flow for secure storage access by a secure interface control in accordance with one or more embodiments of the invention;

FIG. 12 depicts a process flow for access tagging by a security interface control and by hardware in accordance with one or more embodiments of the invention;

FIG. 13 depicts a process flow supporting the translation of secure and non-secure access of programs and secure interface controls in accordance with one or more embodiments of the invention;

FIG. 14 depicts a process flow of DAT with secure storage protection by a program and by a secure interface control in accordance with one or more embodiments of the invention;

FIG. 15 depicts a process flow for secure interface control advanced page management in accordance with one or more embodiments of the invention;

FIG. 16 depicts a process flow for secure interface control advanced page management in accordance with one or more embodiments of the invention;

FIG. 17 illustrates a cloud computing environment in accordance with one or more embodiments of the invention;

FIG. 18 depicts abstraction model layers in accordance with one or more embodiments of the invention;

FIG. 19 depicts a system in accordance with one or more embodiments of the invention; and

FIG. 20 depicts a processing system in accordance with one or more embodiments of the invention.

The figures depicted herein are illustrative. Many changes may be made to the diagrams or operations described herein without departing from the spirit of the invention. For instance, the actions may be performed in a differing order, or actions may be added, deleted or modified. Likewise, the term "coupled" and its variants describe a direct connection having a communication path between two elements and do not imply that there are no intervening elements/connections between the elements. All such variations are considered a part of the specification.

Detailed Description

One or more embodiments of the invention provide an additional layer of security, referred to herein as a secure interface control, for a Virtual Machine (VM) executing on a host under the control of an untrusted entity. In particular, the secure interface control provides such additional security with an efficient, lightweight trusted firmware interface between a secure entity (e.g., a guest, VM, or container) and an untrusted entity (e.g., an untrusted, unsecure entity, a host, a virtual machine monitor, or an operating system). The secure interface control maintains and uses a registration mapping between the host virtual address and the host absolute address of any secure pages to allow untrusted entities to continue to provide page management functionality for those pages while still providing a high level of security. In this regard, with the new interface, the secure interface control and the untrusted entity may provide a page management approach in which the untrusted entity is allowed to continue to manage secure client pages without requiring the secure interface control to maintain shadow tables (and the high performance costs associated therewith), while the secure interface control ensures the security of these page mappings.

Technical effects and benefits of one or more embodiments of the present invention may include prohibiting access to secure storage by all non-secure clients and virtual machine monitors. Moreover, technical effects and benefits of one or more embodiments of the invention described herein may include the virtual machine monitor ensuring that, for any given resident secure guest page, the associated host absolute address is only accessible through a single virtual machine monitor (host) DAT mapping (i.e., there is a single host virtual address that maps to any given host absolute address assigned to the secure guest); the virtual machine monitor DAT mapping associated with any given secure guest page (host virtual to host absolute) does not change when it is paged in; also, the host absolute page associated with any secure guest page is mapped only for a single secure guest. Furthermore, there is no storage sharing between secure clients, as storage is shared between a single secure client and a virtual machine monitor controlled by the secure client.

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

To facilitate and support a secure client (e.g., a secure entity), there are technical challenges in which additional security is required between the virtual machine monitor and the secure client without relying on the virtual machine monitor, such that the virtual machine monitor cannot access data from the VM, and thus cannot provide services in the manner described herein.

The secure execution described herein provides a hardware mechanism to ensure isolation between secure and non-secure storage and between secure storage belonging to different secure users. For the secure client, additional security is provided between the "untrusted" (untrusted) non-secure virtual machine monitor and the secure client. To this end, a virtual machine monitor typically performs many functions on behalf of a client that need to be incorporated into a machine. A new secure interface control (also referred to herein as "UV") is described for providing a secure interface between a virtual machine monitor and a secure client. The terms secure interface control and ultravisor are used interchangeably herein. The secure interface control works in cooperation with the hardware to provide this additional security.

In one example, the secure interface control is implemented in internal, secure, and trusted hardware and/or firmware. For secure clients or entities, the secure interface control provides initialization and maintenance of the secure environment and coordinates the scheduling (dispatch) of these secure entities on the hardware. When a secure client is actively using data and it resides in host storage, it remains "safe" in the secure storage. The secure client storage may be accessed by the single secure client — this is strictly enforced by hardware. That is, the hardware prevents any non-secure entity (including a virtual machine monitor or other non-secure client) or different secure client from accessing the data. In this example, the secure interface control runs as the lowest level trusted portion of the firmware. The lowest layer or millicode is actually an extension of hardware and is used to implement, for example, IBMThe complex instructions and functions defined in (1). Millicode has access to all portions of storage, including its own secure UV storage, non-secure virtual machine monitor storage, secure client storage, and shared storage, in the context of secure execution. This allows it to provide whatever functionality is required by the secure client or by the virtual machine monitor to support the client. The secure interface control also has direct access to the hardware, which allows the hardware to effectively provide security checks under the control of the conditions established by the secure interface control.

In accordance with one or more embodiments of the present invention, a secure-storage bit is provided in hardware to mark a secure page. When the bit is set (set), the hardware prevents any non-secure clients or virtual machine monitors from accessing this page. In addition, each secure or shared page is registered in a partition security table and marked with a secure client domain Identification (ID). When the page is non-secure, it is marked as non-secure in the partition security table. This partition security table is maintained by the security interface control of each partition or zone. There is one entry per host absolute page that the hardware uses to verify if the page is only accessed by the secure client or the entity owning the page when the secure entity does any DAT translations.

According to one or more embodiments of the invention, the software uses a UV Call (UVC) instruction to request the security interface control to perform a particular action. For example, the UVC instructions may be used by a virtual machine monitor to initialize secure interface controls, 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 (import) (decrypt and assign to secure guest domain) and export (export) (encrypt and allow host access) secure guest pages as part of a virtual machine monitor page-in or page-out operation. In addition, the secure client has the ability to define shared storage with the virtual machine monitor, have the secure storage shared, and have the shared storage secure.

To provide security, a secure interface control in cooperation with hardware provides and ensures decryption and encryption of data as the virtual machine monitor transparently pages secure guest data in and out. To accomplish this, the virtual machine monitor is required to issue new UVCs when paging secure client data in and out. Based on the controls set by the security interface controls during these new UVCs, the hardware will ensure that these UVCs are indeed issued by the virtual machine monitor.

In this new secure environment, whenever the virtual machine monitor pages out a secure page, a new transition needs to be issued from the secure store (export) UVC. In response to deriving the UVC, the secure interface control will 1) indicate that the page is UV "locked", 2) encrypt the page, 3) set the page to unsecure, and 4) reset the UV lock. Once the export UVC is complete, the virtual machine monitor can now page out the encrypted guest page.

In addition, whenever the virtual machine monitor pages into a secure page, it must issue a new transition to the secure store (import) UVC. In response to this introduction of UVC, the UV or secure interface control will 1) mark the page as secure in hardware, 2) indicate that the page is UV "locked", 3) decrypt the page, 4) set the permissions to the particular secure client domain, and 5) reset the UV lock. The hardware performs authorization checks (authorization checks) on the page during translation each time the security entity makes an access. These checks include: 1) a check to verify that the page does belong to the secure client domain that accessed it; and 2) ensure that the virtual machine monitor does not change the checking of the host mapping (host mapping) for the page while the page is already resident in guest memory. Once a page is marked as secure, the hardware prevents the virtual machine monitor or non-secure guest VM from accessing any secure page. These additional translation steps prevent access by another secure VM and prevent remapping (remapping) of the virtual machine monitor.

Turning now to FIG. 1, a table 100 for partition security is generally shown in accordance with one or more embodiments of the invention. The partition security table 100 shown in FIG. 1 is maintained by the security interface control and is used by the security interface control and hardware to ensure secure access to any page accessed by the security entity. The partition security table 100 is indexed by host absolute address 110. I.e. one entry for each page that the host absolutely stores. Each entry includes information for verifying that the entry belongs to a secure entity that is accessing.

Further, as shown in FIG. 1, the partition security table 100 includes a security domain ID 120 (identifying the security domain associated with this page); UV-bit 130 (indicating that the page is donated to and owned by the security interface control); disable address compare (DA) -bit 140 (to disable host address pair comparison in certain cases, such as when a secure interface control page defined as a host absolute address does not have an associated host virtual address); shared (SH) -bit 150 (indicating the page shared with the non-secure virtual machine monitor) and host virtual address 160 (indicating the host virtual address registered for this host absolute address, which is referred to as a host-address pair). Note that the host-address pair indicates the host absolute and associated, registered host virtual addresses. Once imported by the virtual machine monitor, the host-address pair represents a mapping of the page, and the comparison ensures that the host does not remap the page when the guest uses the page.

Dynamic Address Translation (DAT) is used to map virtual storage to real storage. When a guest VM runs as a pageable guest under the control of a virtual machine monitor, the guest uses DAT to manage the memory pages residing therein. Furthermore, when a page resides in its memory, the host uses DAT independently to manage those guest pages (along with its own pages). The virtual machine monitor uses DAT to provide isolation and/or sharing of storage between different VMs and to prevent guests from accessing the virtual machine monitor storage. When the guest is running in a non-secure mode, the virtual machine monitor can access all of the guest's storage.

DAT enables isolation of one application from another while still allowing them to share common resources. DAT also allows for the implementation of VMs that can be used to design and test new versions of the OS as well as concurrent processing of applications. The virtual address identifies a location in the virtual storage. The address space is a contiguous sequence of virtual addresses, along with specific transformation parameters (including a DAT table) that allow each virtual address to be translated into an associated absolute address that identifies the address in byte position in storage.

DAT uses a multi-table lookup to translate a virtual address to an associated absolute address. This table structure is typically defined and maintained by a storage manager. This memory manager transparently shares absolute memory among multiple programs by paging out, for example, one page to bring in another page. When a page is paged out, the memory manager will set an invalid bit, for example, in the associated page table. When a program attempts to access a paged out page, the hardware will submit a program interrupt, commonly referred to as a page fault, to the memory manager. In response, the storage manager pages the requested page and resets the invalid bit. This is done transparently to the program and allows the storage manager to virtualize the storage and share it among various different users.

When a CPU accesses a main memory with a virtual address, the virtual address is first converted into a real address (real address) by DAT and then converted into an absolute address by prefix (prefix). The name (designation) (origin and length) of the highest level table for a particular address space is called the Address Space Control Element (ASCE) and defines the associated address space.

Turning now to FIG. 2, an example virtual address space 202 and 204 and an absolute address space 206 for performing DAT are generally shown, in accordance with one or more embodiments of the present invention. In the example shown in FIG. 2, there are two virtual address spaces: a virtual address space 202 (defined by Address Space Control Element (ASCE) a 208) and a virtual address space 204 (defined by ASCE B210). Virtual pages A1. V212 a1, A2. V212 A2, and A3. V212 a3 are mapped by the storage manager with ASCE A208 in a multi-table (segment)230 and page tables 232a, 232b) lookup to absolute pages A1. A220 a1, A2. A220 A2, and A3. A220 a3. Similarly, virtual pages B1. V214B 1 and B2. V214B 2 are mapped to absolute pages B1. A222B 1 and B2. A222B 2, respectively, in two table 234 and 236 lookups using ASCE B210.

Turning now to FIG. 3, an example of a nested multipart DAT translation for supporting VMs running under a virtual machine monitor is generally shown in accordance with one or more embodiments of the present invention. In the example shown in fig. 3, both client a's virtual address space a 302 (defined by client asce (gasce) a 304) and client B's virtual address space B306 (defined by gaseb 308) reside in a shared host (virtual machine monitor) virtual address space 325. As shown, virtual pages a1.gv 310a1, a2.gv 310a2, and a3.gv 310a3 belonging to guest a are mapped by the storage manager of guest a with GASCEA 304 to guest absolute pages a1.hv 340a1, a2.hv 340a2, and a3.hv 340a3, respectively; virtual pages B1.gv 320bl and B2.gv 320B2 belonging to client B are mapped by client B's storage manager to client absolute pages B1.hv 360bl and B2.hv 360B2, respectively, independently with gaseb 308. In this example, these guest absolute pages map directly into the shared host virtual address space 325, and then undergo additional host DAT translations to the host absolute address space 330. As shown, host virtual addresses a1.hv 340a1, a3.hv 340a3, and b1.hv 360b1 are mapped by the host storage manager with host asce (hasce)350 to a1.ha 370a1, a3.ha 370a3, and b1.ha 370b 1. Both the host virtual address a2.hv 340a2 belonging to guest a and the B2.hv 360B2 belonging to guest B are mapped to the same host absolute page, ab2.ha 380. This enables data to be shared between the two clients. During client DAT translation, each client table address is treated as a client absolute address and undergoes additional nested host DAT translations.

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

According to one or more embodiments of the invention, storage sharing between secure clients is also prohibited. Storage is shared between a single secure client and a virtual machine monitor under the control of the secure client. The UV storage is secure storage, accessible through the secure control interface, but not accessible by the client/host. The virtual machine monitor allocates storage to the security control interface. According to one or more embodiments of the invention, the hardware and security control interfaces prohibit any attempt to violate these rules.

Turning now to FIG. 4, an example of a mapping of secure client storage is generally shown in accordance with one or more embodiments of the invention. Fig. 4 is similar to fig. 3 except that the example of fig. 4 does not allow for sharing of storage between secure client a and secure client B. In the non-secure example of fig. 3, both the host virtual address a2.hv 340a2 belonging to guest a and the B2.hv 360B2 belonging to guest B are mapped to the same host absolute page, ab2.ha 380. In the secure guest storage example of fig. 4, the host virtual address a2.hv 340a2 belonging to guest a maps to the host absolute address a2.ha 490a, while the B2.hv 360B2 belonging to guest B maps to its own B2.ha 490B. In this example, there is no sharing between secure clients.

When the secure client page resides on disk, it is encrypted. When the virtual machine monitor pages into a secure guest page, the virtual machine monitor issues a UV call (UVC) that causes the secure interface control to mark the page as secure (unless shared), decrypt the page (unless shared), and register (in the partition security table) the page as belonging to the appropriate secure guest (e.g., guest a). In addition, the virtual machine monitor 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 virtual machine monitor fails to issue the correct UVC, it receives an exception when it attempts to access the secure guest page. When the virtual machine monitor pages out of the guest page, a similar UVC is issued that encrypts the guest page (unless shared) before marking it as insecure and registering it as insecure in the partition security table.

In the example with five given host absolute pages K, P, L, M and N, each of the host absolute pages is marked as safe by the secure interface control when the virtual machine monitor pages them in. This prevents non-secure clients and virtual machine monitors from accessing them. When the virtual machine monitor pages into host absolute pages K, P and M, host absolute pages K, P and M are registered as belonging to guest A; when the virtual machine monitor pages into host absolute pages L and N, host absolute pages L and N are registered with guest B. Shared pages (pages shared between a single secure guest and a virtual machine monitor) are not encrypted or decrypted during paging. They are not marked as secure (allowing access by the virtual machine monitor) but are registered with a single secure client domain in the partition security table.

In accordance with one or more embodiments of the invention, a secure-storage access (PIC3D) exception is received by a virtual machine monitor when a non-secure guest or virtual machine monitor attempts to access a page owned by a secure guest. This is determined without the need for an additional conversion step.

In accordance with one or more embodiments, when a secure entity attempts to access a page, the hardware performs an additional translation check that verifies that the store does belong to a particular secure client. If not, a non-secure access (PIC3E) exception is submitted to the virtual machine monitor. Further, if the translated host virtual address does not match a host virtual address of a registered host-address pair in the partition security table, a secure storage violation ('3F' x) exception is identified. To enable sharing with the virtual machine monitor, the secure client may access storage that is not marked as secure as long as the translation check allows access.

Turning now to FIG. 5, a system diagram 500 of DAT operation in accordance with one or more embodiments of the present invention is shown generally. System diagram 500 includes a host primary virtual address space (host primary virtual address space)510 and a host home virtual address space (host home virtual address space)520 in which pages are translated (see, e.g., host DAT translation 525; note that the dashed lines represent the mapping through DAT translation 525) into a virtual machine monitor (host) absolute address space 530. For example, FIG. 5 illustrates the sharing of host absolute storage by two different host virtual address spaces, and also illustrates the sharing of one of those host virtual addresses not only between two guests, but additionally with the host itself. In this regard, host base virtual address space 510 and host local virtual address space 520 are examples of two host virtual address spaces, each of which is addressed by a separate ASCE-host base ASCE (HPASCE)591 and host local ASCE (HHASCE) 592-, respectively. Note that all secure interface control stores (virtual and real) are donated by the virtual machine monitor and marked as secure. Once donated, the secure interface control store is only accessible by the secure interface control as long as the associated secure entity exists.

As shown, host base virtual address space 510 includes guest A absolute page A1.HV, guest A absolute page A2.HV, guest B absolute page B1.HV, and host virtual page H3. HV. The host native virtual address space 520 includes a security-interface-control virtual page u1.hv, a host virtual page h1.hv, and a host virtual page h2. hv.

In accordance with one or more embodiments of the invention, all secure guests (e.g., secure guest a and secure guest B) stored in the partition security table described herein are registered as belonging to the secure guest configuration, and the associated host virtual address (e.g., a1.hv, a2.hv, B1.hv) is also registered as part of the host-address pair. In one or more embodiments, all secure guest storage is mapped in the host base virtual space. In addition, all security interface control stores are also registered in the partition security table as belonging to security interface controls, and may be further differentiated in the partition security table based on the associated security client domain. According to one or more embodiments of the invention, the UV virtual memory is mapped in the host local virtual space and the associated host virtual addresses are registered as part of a host-address pair. In accordance with one or more embodiments, the UV real storage does not have an associated host virtual mapping, and the DA bit (which indicates that virtual address comparison is disabled) in the partition security table is set to indicate this. Host storage is marked as non-secure and is also registered as non-secure in the partition security table.

Thus, in the case of "guest absolutely-host virtual", the virtual machine monitor (host) primary DAT table (defined by HPASCE 591) translates the pages of the host base virtual address space 510 as follows: guest a absolute page a1.hv is mapped to host absolute page a1.ha belonging to secure guest a; guest a absolute page a2.hv is mapped to host absolute page a2.ha belonging to secure guest a; guest B absolute page B1.hv is mapped to host absolute page B1.ha belonging to secure guest B; host virtual page h3.hv is mapped to host absolute page h3.ha non-secure host (no host-address pair, since it is non-secure). Further, the virtual machine monitor (host) master DAT table (defined by HHASCE 592) translates pages of the host local virtual address space 520 as follows: the secure interface control virtual page u1.hv is mapped to the host absolute page u1.ha defined as secure UV virtual; host virtual page h1.hv is mapped to host absolute page h1.ha defined as non-secure; the host virtual page h2.hv is mapped to a host absolute page h2.ha that is defined to be non-secure. There are no host-address pairs associated with either the h1.ha or the h2.ha because they are insecure.

In operation, if a secure client attempts to access a secure page assigned to a secure interface control, the hardware submits a secure storage violation ('3F' X) exception to the virtual machine monitor. If a non-secure guest or virtual machine monitor attempts to access any secure pages, including those allocated to the secure interface control, the hardware submits a secure storage access ('3D' X) exception to the virtual machine monitor. Alternatively, an attempted access to the secure interface control space may be upon a commit error condition (error condition). If the hardware detects a mismatch in the security assignment on the secure interface control access (e.g., a host-address pair stored in the partition security table that is registered as belonging to a secure client rather than to a secure interface control, or that is in use does not match a registered pair), a check is submitted.

In other words, host base virtual address space 510 includes host virtual pages A1.HV and A2.HV (belonging to secure guest A) and B1.HV (belonging to secure guest B), which map to host absolute A1.HA, A2.HA and B1.HA, respectively. Further, host base virtual address space 510 includes host (virtual machine monitor) pages h3.hv, which map to host absolute h3. ha. The host native virtual space 520 includes two host virtual pages, H1.HV and H2.HV, which map to host absolute pages, H1.HA and H2. HA. Both the host base virtual address space 510 and the host home virtual address space 520 are mapped into a single host absolute space 530. Memory pages belonging to secure client a and secure client B are marked as secure and registered with their security domains and associated host virtual addresses in the partition security table 100 shown in fig. 1. On the other hand, host memory is marked as non-secure. When the virtual machine monitor defines a secure client, it must donate host storage to the secure interface control for the secure control blocks needed to support these secure clients. The storage may be defined in a host absolute or host virtual space, and in one example, specifically in a host local virtual space. Returning to fig. 5, host absolute pages u1.ha and u2.ha secure UV are absolutely secure interface control stores defined as host absolute stores. Thus, these pages are marked as secure and are registered in the partition security table 100 shown in FIG. 1 as belonging to a secure interface control and having an associated security domain. Because these pages are defined as host absolute addresses, there is no associated host virtual address, so the DA bit in partition security table 100 is set.

An example of the translated virtual machine monitor (host) absolute address space 530 can be seen in FIG. 6. FIG. 6 is a system diagram 600 depicting a secure interface control store in accordance with one or more embodiments of the invention. System diagram 600 shows a virtual machine monitor (host) absolute address space 630, which includes host absolute pages a2.ha secure guest a (for a2. hv); host absolute page B1.ha secure guest B (for B1. hv); host absolute page h1.ha non-secure (host); host absolute page h2.ha unsecure (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 guest a (for a1. hv).

Turning now to FIG. 7, a process flow 700 for a import operation is generally shown in accordance with one or more embodiments of the present invention. When a secure guest accesses a page paged out by a virtual machine monitor, a sequence of events, such as that shown in process flow 700, occurs in order to securely page back the page. Process flow 700 begins at block 705 where a secure client accesses a guest virtual page. Since the page is, for example, invalid, the hardware submits a host page fault to the virtual machine monitor as indicated by the program interrupt code 11(PIC11) (see block 715). The virtual machine monitor in turn identifies available non-secure host absolute pages for the guest page (see block 720) and pages the encrypted guest page into the identified host absolute page (see block 725).

The host absolute page is then mapped in the appropriate host DAT table (based on the host virtual address) at block 730. The virtual machine monitor host then reschedules the secure guest at block 735. At block 740, the secure client re-accesses the client secure page. The page fault no longer exists, but since this is a secure guest access and the page is not marked as secure in partition security table 100 of diagram 100, the hardware commits a non-secure storage exception to the virtual machine monitor at block 745 (PIC 3E). This PIC3E blocks the client's access to this secure page until the necessary import has been issued. Next, process flow 700 proceeds to "A" continuing to FIG. 8.

Turning now to FIG. 8, a process flow 800 for performing an import operation is generally illustrated in accordance with one or more embodiments of the present invention. In response to PIC3E, the well-behaved (e.g., executed in an expected manner without error) virtual machine monitor 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 virtual machine monitor, other non-secure entities, and secure interface controls. It cannot be accessed by the secure client.

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

At decision block 822, the secure interface control checks to see if the page is a page shared with a non-secure virtual machine monitor. If it is shared (process flow 800 proceeds to decision block 824), the secure interface control registers and registers the host absolute address with the associated secure guest domain, host virtual address as shared in the partition security table. This page remains marked as non-secure. This completes importing the UVC, which is now available for access by the client. Processing continues with the virtual machine monitor rescheduling the client (block 830) and the secure client successfully accesses the page (block 835).

If the host virtual page to be imported is not shared with the virtual machine monitor (process flow 800 proceeds to block 840), the secure interface control marks the page as secure so that the virtual machine monitor can no longer access the page. At block 845, the secure interface control locks the page so that no other UVC can modify the page state. Once the lock is set (at block 850), the secure interface control will verify that the contents of the client page have not changed while it was encrypted. If the contents of the guest page do change, an error return code is returned to the virtual machine monitor, otherwise the secure interface control will decrypt the secure page.

At block 855, the security interface control unlocks the page (thereby allowing access by other UVCs), registers the page as secure in the partition security table and associated with the appropriate guest domain and host virtual address to complete the host-address HV- > HA pair. This allows the client to access and complete the UVC.

Turning now to FIG. 9, a process flow 900 is generally shown with respect to a donation memory operation in accordance with one or more embodiments of the invention. Process flow 900 begins at block 905 with the virtual machine monitor issuing a query UVC to a secure interface control. At block 910, the secure interface control returns data (e.g., query UVC). This data may include the amount of base partition specific host-absolute storage required; the amount of basic security-client-domain specific host-absolute storage required; the amount of variable security-client-domain specific host-virtual storage required per MB; and/or the amount of basic security-client-CPU specific host-absolute storage required.

At block 915, the virtual machine monitor reserves storage specific to the underlying host-machine absolute partition (e.g., based on the size returned by the query UVC). At block 920, the virtual machine monitor issues an initialization (initialization) to the secure interface control. In this regard, the virtual machine monitor may issue an initialization UVC that provides donated storage for the UV control block needed to coordinate between secure client configurations for the entire partition. The initialization UVC specifies the storage source specific to the base partition.

At block 925, the secure interface control effects initialization (e.g., initializing UVC) by registering the donated storage to UV and marking as secure. To enable initialization of UVC, the secure interface control may mark donated storage as secure; allocating some of the donated storage for the partition security table; and registering the donated storage with the unique security-domain for UV use in the partition security table, but not with the associated security-client-domain, and as not having an associated host-virtual address pair.

At block 930, the virtual machine monitor reserves storage (e.g., base and variable security-client-domain specific storage). For example, the virtual machine monitor reserves basic and variable (e.g., based on the size of the security-client-domain storage) security-client-domain specific storage (e.g., the size returned by the query UVC). At block 935, the virtual machine monitor issues a create configuration to the secure interface control. In this regard, the virtual machine monitor may issue a create-secure-client-configuration (UVC) specifying a storage source specific to the base and mutable secure-client-domains. Further, the create-secure-client-configuration UVC provides donated storage for the UV control blocks needed to support the secure client configuration.

At block 940, the secure interface control implements create configuration (e.g., create-secure-client-configuration UVC). To implement create-secure-client-configure UVC, the secure interface control may mark donated storage as secure; registering the donated storage in a partition safety table for use by UV; and registers the donated storage with the associated security-client-domain. The donated base (host-absolute) storage is registered as not having an associated host-virtual address pair. The donated variable (host-virtual) storage is registered with the associated host-virtual address.

At block 945, the virtual machine monitor reserves substantially secure-client-CPU-specific storage (e.g., size returned by query-UV). At block 950, the virtual machine monitor specifies a storage source. For example, the virtual machine monitor issues a create-secure-client-CPU (create-secure-guest-CPU) to the UV that specifies a substantially secure-client-CPU-specific storage source. At block 955, the secure interface control implements the create-CPU (e.g., create-secure-client-CPU UVC). To implement the create-secure-client-CPU UVC, the secure interface control may mark the donated storage as secure and register the donated storage for UV use in a partition security table, but not with the associated secure-client-domain, and register as not having an associated host-virtual address pair.

Turning now to FIG. 10, a process flow 1000 is generally shown in connection with the conversion of a non-secure virtual machine monitor page to a secure page of a secure interface control in accordance with one or more embodiments of the present invention. In process flow 1000, three virtual machine monitor pages (e.g., non-secure virtual machine monitor page a, non-secure virtual machine monitor page B, and non-secure virtual machine monitor page C) are shown.

Virtual machine monitor (non-secure) pages A, B and C are accessible by non-secure entities, including the virtual machine monitor. Further, virtual machine monitor (non-secure) pages A, B and C are marked as non-secure (NS) and are registered as non-secure and non-shared in a partition security table (e.g., partition security table 100 shown in FIG. 1). At arrow 1005, an initialization UVC is issued that transitions client page a to a secure interface control real storage page 1010 associated with the entire partition (UV 2). The secure interface control real store 1010 may be marked as secure and registered in a partition security table (e.g., partition security table 100 shown in fig. 1) as UV without guest domain and without virtual machine monitor to host absolute (HV- > HA) mapping. Instead, it registers with a unique UV2 security domain and sets the DA bit to 1. Note that the secure interface control real storage 1010 is accessible as a real by secure interface control.

At arrow 1025, a create-SG-configuration (create-SG-config) or create-SG-CPU (create-SG-CPU) UVC is issued from the virtual machine monitor (non-secure) page B, which translates the page to a secure interface control real storage 1030 associated with a secure client domain (UVS). Secure interface control real store 1030 may be marked as secure and registered in a partition security table (e.g., partition security table 100 shown in fig. 1) as a UV with an associated secure guest domain and without a virtual machine monitor to host absolute mapping (HV- > HA) (i.e., DA bit 1). Note that the secure interface control real storage 1010 is accessible by the secure interface control as a real on behalf of the secure client domain.

At arrow 1045, a create-SG-configuration UVC is issued from virtual machine monitor (non-secure) page C, which translates the page to secure interface control virtual storage 1050 associated with a secure client domain (UVV). Secure interface control virtual storage 1050 can be marked as secure and registered in a partition security table (e.g., partition security table 100 shown in fig. 1) as a UV with secure guest domain and virtual machine monitor to host absolute (HV- > HA) mappings. Note that the secure interface control virtual store 1050 may be accessed as a UV virtual on behalf of the secure client domain.

Turning now to FIG. 11, a process flow 1100 is shown with respect to secure storage access by a program or secure interface control in accordance with one or more embodiments. This represents a situation where the secure interface control is about to access the client store or the secure interface control store and the access must be properly marked in order to allow the hardware to verify the security of the access. Process flow 1100 depicts such labeling of storage access to a secure interface control. Process flow 1100 begins at block 1110 where the secure interface control determines whether it is accessing a secure interface control store.

If this is not an access to a secure interface control store, 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 the secure client store, process flow 1100 proceeds to "B" (which connects to process flow 1200 of FIG. 12), which will use the default settings for secure client access. If this is an access to a secure client store, process flow 1100 proceeds to decision block 1113 where the secure interface control determines whether the default secure client domain is being used. If so, process flow 1100 proceeds to "B" (which connects to process flow 1200 of FIG. 12), which will use the default settings for secure client access. 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 connects to process flow 1200 of fig. 12).

If this is an access to a secure interface control store, process flow 1100 proceeds to block 1120 (as indicated by the Yes arrow). At block 1120, the access is marked as safe UV (e.g., using a UV-safe-domain register).

Process flow 1100 then proceeds to decision block 1130, where the security interface control determines whether this is an access to a UVV space (e.g., an SG-configuration Variable Table). If it is an access to UVV space, process 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-secure-domain register. At block 1138, DAT translation and access storage are ready, which may begin. Returning to decision block 1130, if this is not an access to UVV space, process flow 1100 proceeds to block 1140 (as indicated by the no arrow). At block 1140, the access is marked as real.

At decision block 1150, the security interface control determines whether this is an access to the UVS space (e.g., SG configuration or CPU table). If this is an access to the UVS space, process flow 1100 proceeds to block 1136 (as indicated by the YES arrow). If this is not an access to the UVS space, then process flow 1100 proceeds to block 1170 (as indicated by the no arrow). This access is then simply an access to the UV2 space (e.g., partition security table). At block 1170, the unique UV2 security domain is loaded into the UV-secure-domain register.

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

FIG. 13 depicts an example of a translation performed by hardware to support both secure and non-secure accesses in a process flow 1300 in accordance with one or more embodiments of the invention. At block 1305, the hardware may determine whether the access is marked as guest translation, and if so, and determine at block 1310 that the access is virtual, then the guest DAT may be executed at block 1315. During client DAT translation, there may be nested intermediate fetches (nested, intermediate fetches for guest DAT tables) of the client DAT table. If the original translation is marked as secure, table fetches may be marked as client real and secure. Table retrieval may also follow the conversion process of process flow 1300. After performing client DAT for any access marked as guest virtual at block 1315 and for any access marked as guest real at block 1310 (virtual no), the guest prefix and guest memory offset may be applied at block 1320. Upon completion of the guest translation process, at block 1325, if the original guest translation is marked as secure, the resulting address may be marked as host virtual and marked as secure. Process 1300 may continue as for any access marked as host virtual. If it is determined at block 1305 that the original access is a host access (guest no) and it is determined at block 1330 to be marked as virtual, then host DAT may be performed at block 1335. At block 1335, the host table acquisition may be marked as non-secure. After the host DAT is executed at block 1335, or if it is determined at block 1330 that the original host access is marked as real (virtual no), the host prefix may be applied at block 1340. At block 1345, the resulting address may be a host absolute address.

FIG. 14 depicts an example of DAT translation with secure storage protection that can be performed by hardware in process flow 1400 in accordance with one or more embodiments of the invention. Continuing from block 1345 of fig. 13, if secure-UV access is identified at block 1405, the hardware may verify whether the store is registered as a secure-UV store at block 1410, and if not, commit an error at block 1415. When accessing the UV storage, the security control interface may perform secure-UV access. If it is determined at block 1410 that the store is registered as a secure-UV store, then the protection check may proceed as for any secure accesses, except that the UV-secure-domain register (set by the security control interface prior to making the secure UV access) may be used as the specified security domain for the domain check at block 1420 to which processing proceeds. Additionally, any violations for UV access detected at block 1425 (entry point D) may be committed as an error at block 1430, rather than committing an exception to the virtual machine monitor at block 1435 as was done for secure client violations (secure-UV ═ no) at block 1425.

For accesses that are not marked as safe-UV accesses at block 1405, the hardware determines whether the access is a secure guest access at block 1440, and if not and if the page is marked as secure at block 1445, an exception may be submitted to the virtual machine monitor at block 1435. Otherwise, if it is determined at block 1440 that the access is not a secure client access and the page is not marked as secure at block 1445, the translation is successful at block 1450.

If the access is a secure client access at block 1440 or a secure-UV access to a store registered as a secure-UV store at block 1410, the hardware may check to ensure that the store is registered with a secure entity associated with the access at block 1420. If this is a secure-UV access, the specified security domain may be obtained from the UV-secure-domain register (loaded by the security control interface based on the secure-UV store being accessed) and from the SG-secure-domain register (loaded when the secure entity is dispatched) for secure-client access. If the storage being accessed at block 1420 is not registered to the specified security domain, then an error occurs at block 1430 for the secure-UV access at block 1425, and an exception is submitted to the virtual machine monitor at block 1435 for the secure-client access at block 1425 (secure-UV — NO).

For secure access to storage registered to the specified security domain at block 1410, at block 1440, and at block 1420, if the virtual address check is disabled at block 1455, i.e., the DA bit is 1, and the access is real at block 1460, then at block 1450, the translation is complete. However, if the DA bit is 1 at block 1455 but the access is virtual at block 1460 (real no), then an error occurs at block 1430 for the secure-UV access at block 1425 and an exception is committed to the virtual machine monitor at block 1435 for the secure-client access at block 1425 (secure-UV no). If the DA bit is 0 at block 1455 and the access is a virtual access at block 1475, the hardware may determine if the host virtual-to-host absolute mapping of the access matches the mapping registered for the host absolute address at block 1470. If so, at block 1450, the transition is successfully completed. If the mappings do not match at block 1470, then an error is taken at block 1430 for the secure-UV access at block 1425, and an exception is submitted to the virtual machine monitor at block 1435 for the secure-client access at block 1425 (secure-UV ═ no). If the DA bit is 0 and the access is real access (virtual no) at block 1475, then an error occurs at block 1430 for the secure-UV access at block 1425 and an exception is committed to the virtual machine monitor at block 1435 for the secure-client access at block 1425 (secure-UV no); alternatively, the conversion may be successfully completed at block 1450. Any accesses by the I/O subsystem may be checked at block 1480 to see if the page is marked as safe at block 1445, and if the page is safe, an exception may be committed to the virtual machine monitor at block 1435; if the page is not marked as safe, at block 1450, the conversion is successful.

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

Dynamic Address Translation (DAT) is used to map virtual storage to real storage. When a guest VM runs as a pageable guest under the control of a virtual machine monitor, the guest uses DAT to manage the pages residing in its memory. Furthermore, when a page resides in its memory, the host uses DAT independently to manage those guest pages (along with its own pages). The virtual machine monitor uses DAT to provide the necessary isolation and/or sharing of storage between different VMs and to prevent guests from accessing the virtual machine monitor storage. The virtual machine monitor may access the storage of all clients.

As described herein, one or more embodiments of the present invention provide this additional security using an efficient, lightweight secure interface control interface between software and the machine. In this regard, using the interface as such enables the secure interface control and virtual machine monitor to provide page management in a manner that allows the virtual machine monitor to continue managing secure guest pages while the machine (secure interface control and hardware) ensures the security of these page mappings.

In one or more embodiments, secure execution provides a hardware mechanism to ensure isolation between secure and non-secure storage and between secure storage belonging to different secure users. For the secure client, additional security is provided between the "untrusted" virtual machine monitor and the secure client. To this end, many of the functions that a virtual machine monitor typically performs on behalf of a client are incorporated into the machine through a control structure called a secure interface control (UV). The secure interface control provides a secure interface between the virtual machine monitor and the secure client. The security interface control works in conjunction with the machine hardware to provide this additional security.

The secure interface control is a protection mechanism provided for a virtual machine that uses the virtual machine schedule as a primary transition point (i.e., between the virtual machine monitor and the secure client) or a virtual executable that uses another boundary (e.g., address space change) as a primary transition point.

In one example, the secure interface control (e.g., ultravisor) is implemented in internal, secure, and trusted firmware. For secure clients or entities, the secure interface controls provide initialization and maintenance of the secure environment, as well as coordination of the scheduling of these secure entities on the hardware. When a secure client is actively using data and it resides in host storage, it will maintain a "safe" (in the clear) state in secure storage. The secure storage is accessible by the single secure client, which is strictly performed by hardware. That is, the hardware prevents any non-secure entity (including a virtual machine monitor or other non-secure client) or different secure client from accessing the data. In this example, the secure interface control runs as a trusted part of the lowest level firmware. The lowest level has access to all portions of the storage, such as its own secure UV storage, non-secure virtual machine monitor storage, secure client storage, and shared storage. This access allows the secure interface control to provide any functionality required by the secure client or virtual machine monitor to support the client. In addition, the secure interface control may also have direct access to the hardware, which allows the hardware to effectively provide security checks under the conditional control established by the secure interface control.

The software uses an instruction call (e.g., a UV call (UVC) instruction) to request the secure interface control to perform a particular operation. For example, the virtual machine monitor may initialize secure interface controls using UVC instructions, create a secure client domain (e.g., a secure client configuration), and create a virtual CPU in the secure configuration. The UVC instructions may also be used to import (decrypt and assign to a secure guest domain) and export (encrypt and allow host access) secure guest pages as part of a virtual machine monitor page-in or page-out operation. In addition, the secure client can also define storage shared with the virtual machine monitor, share secure storage, and secure shared storage.

These UVC commands are executed by machine firmware similar to many other architectural instructions. The machine does not enter the secure interface control mode, but executes the secure interface control function in the current operating mode. There is no context switch to handle these operations. This low overhead allows close-coupled collaboration between different layers of software, trusted firmware, and hardware, thereby minimizing and reducing the complexity of the secure interface controls while still providing the necessary level of security.

To provide security, when the virtual machine monitor transparently pages secure guest data in and out, the secure interface controls are provided with the hardware and ensure decryption and encryption of the data. To accomplish this, the virtual machine monitor is required to issue a new UVC when paging in and out of secure client data. The hardware will ensure that these UVCs are indeed issued by the virtual machine monitor based on the controls that the security interface controls set during these new UVCs.

The lightweight UVC design allows virtual machine monitor page management to proceed without the security interface controls tracking the virtual machine monitor table, thus eliminating the significant overhead of providing such tracking. This is accomplished by using a UV call instruction to convert an insecure encrypted page to a secure decrypted page that allows access to only a single secure client domain. As part of this process, the secure interface control ensures that for any secure guest page, the corresponding secure host virtual page is mapped to a single host absolute page, ensures that only a single host virtual address is mapped to any given secure host absolute address, and ensures that the secure page belongs to a single secure guest domain. In addition, the mapping of any secure host virtual address to a particular host absolute page is registered in the secure interface control so that the hardware detects any changes to the mapping and exceptions committed.

In the secure environment described herein, the translation to secure storage (export) UVC needs to be issued each time a virtual machine monitor pages out a secure page. In response to the derived UVC, the UV indicates that the page is in a "transition" state or is UV "locked," encrypts the page, sets the page to non-secure, and resets UV lock. Once the export UVC is complete, the virtual machine monitor may page out the encrypted guest page.

In addition, each time the virtual machine monitor pages into a secure page, it must issue a translation from secure storage (import) UVC. The UV responds to this import of UVC, marks the page as secure in hardware, is in a "transition" state or UV "locked", decrypts the page, and sets the rights to the particular secure client domain. The hardware performs an authorization check on the page during the translation each time the security entity makes an access. These checks include a check to verify that the page does belong to the secure guest domain attempting to access it, and a check to ensure that the virtual machine monitor does not change the host mapping of the page while the page resides in guest memory. Once the page is marked as secure, the hardware will prevent the virtual machine monitor or non-secure guest VM from accessing any secure page. These additional translation steps prevent access by another secure VM and prevent the virtual machine monitor from remapping.

In accordance with one or more embodiments, an additional program interrupt from the machine indicates to the virtual machine monitor that a new additional step is provided. In this case, this additional step may be importing the client page. Until the virtual machine monitor completes this additional step, the hardware prevents the secure guest from accessing the page. This provides the advantage of minimizing duplication of many virtual machine monitor operations in the secure interface control by requiring the secure interface control to perform steps that must be performed in the secure environment for security reasons. This approach, in combination with the checks performed during the introduction of the UVC, eliminates the necessity and associated overhead and complexity of the security interface control to monitor and possibly track the host DAT tables.

In view of the foregoing, the operation of the secure interface control advanced page management will now be discussed in conjunction with FIGS. 15-16. Turning now to FIG. 15, a process flow 1500 for secure interface control advanced page management in accordance with one or more embodiments of the present invention is described. Superimposed in the process flow 1500 are a secure entity (e.g., a VM or a container) 1502, hardware 1504, an untrusted entity (e.g., an untrusted, non-secure entity, a virtual machine monitor, or an operating system) 1506, and secure interface controls 1508 to illustrate which operations are being performed by components of the secure environment.

While process flow 1500 is at block 1510, secure entity 1502 accesses secure pages that have been transparently paged in by untrusted entity 1506 and are still encrypted (marked as non-secure). At block 1520, the hardware 1504 submits a program interrupt to the untrusted entity 1506 indicating that the secure guest page needs to be decrypted. At block 1530, untrusted entity 1506 issues an import UVC (e.g., an import instruction). The import UVC designates host absolute pages and host virtual pages as input parameters.

At block 1535, as part of the execution of the import UVC, the security interface control 1508 determines that the specified host absolute page has not yet been registered as mapped, and then locks the host absolute page for use by the security interface control 1508 (to prevent other UVCs or security entities from accessing the host absolute page). Note that if the page being imported has already been mapped (e.g., the host virtual page has already been mapped to other host absolute pages, or the host absolute page has already been mapped to other host virtual pages), then an error is committed to the non-secure entity. In block 1540, security interface control 1508 marks the page (e.g., the host absolute page) as secure (to prevent access by non-secure entities).

At block 1550, the security interface control 1508 determines that the host virtual page has not yet mapped to a secure absolute page, and then registers the host virtual page for use by the security interface control 1508. Note that if the page being imported has already been mapped (e.g., the host virtual page has already been mapped to other host absolute pages, or the host absolute page has already been mapped to other host virtual pages), then an error is committed to the non-secure entity.

At block 1560, secure interface control 1508 securely decrypts the page for eventual use by the client. At block 1570, security interface control 1508 unlocks the host absolute page and registers the host absolute page as belonging to the security-specific guest domain, and also registers the host virtual-to-host absolute mapping.

For example, the secure interface control 1508 registers the host-absolute page for use by the secure interface control 1508, securely decrypts the host-absolute page, then unregisters (un-register) the host-absolute page for use by the secure interface control 1508, and registers the host-absolute page to the secure domain. In addition, security interface control 1508 registers host virtual addresses with associated host absolute pages to create host-address pairs for use by the security entity and checks for host virtual address matches when accessed by the security entity.

At block 1580, the untrusted entity reschedules the secure entity (e.g., the client or VM). At block 1590, the secure entity re-accesses the now decrypted page without exception.

Turning now to FIG. 16, a process flow 1600 for secure interface control advanced page management is depicted in accordance with one or more embodiments of the present invention. Process flow 1600 overlays a secure entity (e.g., client) 1602, hardware 1604, and an untrusted entity 1606 to illustrate which operations are being performed by components of the secure environment.

While the process flow 1600 is at block 1610, a secure entity (e.g., a client, VM, or container) 1602 accesses the secure virtual pages. For example, the secure entity 1602 has a security domain ID n associated with it and accesses the secure client virtual page x.gv. At block 1620, hardware 1604 performs DAT translation. For example, the hardware 1604 performs DAT translation of guest virtual page x.gv to host virtual page x.hv and host absolute page x.ha.

Next, at decision block 1630, hardware 1604 determines whether the security page is registered as belonging to the security domain that initiated the secure access. For example, hardware 1604 determines whether the security page x.ha is registered to the security domain n. If the security page is not registered to the security domain n, process flow 1600 proceeds to block 1650 (as indicated by the no arrow). At block 1650, hardware 1604 commits a program exception to untrusted entity (e.g., virtual machine monitor) 1606. If the secure page is assigned to a secure client domain, process flow 1600 proceeds to decision block 1670 (as indicated by the YES arrow).

At decision block 1670, the hardware 1604 determines whether the registered host virtual address (corresponding to the registered host address pair) matches the host address pair obtained from the DAT completed for the secure virtual access. For example, the hardware 1604 determines whether the host virtual address registered with the secure page x.ha matches the x.hv obtained by DAT. If the registered address does not match the DAT result, process flow 1600 proceeds to block 1650 (as indicated by the no arrow). At block 1650, hardware 1604 commits the exception to untrusted entity 1606. If the registered address matches the DAT result, process flow 1600 proceeds to block 1690 (as indicated by the YES arrow). At block 1690, if all other protection checks allow secure entity access, hardware 1604 allows secure entity access.

It should be understood that although the present disclosure includes detailed descriptions with respect to cloud computing, implementation of the teachings referenced herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in connection with any other type of computing environment now known or later developed.

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

The characteristics are as follows:

self-service as required: cloud consumers can unilaterally provision computing capabilities, such as server time and network storage, automatically on demand without manual interaction with the service provider.

Wide network access: functionality is provided over a network and accessed through standard mechanisms that facilitate use by heterogeneous thin clients or thick client platforms (e.g., mobile phones, laptops, and PDAs).

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

Quick elasticity: the functions can be quickly and resiliently configured, automatically expanding quickly in some cases, and releasing quickly to contract quickly. The functionality available for configuration generally appears unlimited to the consumer, and may be purchased in any number at any time.

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

The service model is as follows:

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

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

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

The deployment model is as follows:

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

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

Public cloud: the cloud infrastructure is available to the public or large industry groups and is owned by organizations that sell cloud services.

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

Cloud computing environments are service-oriented, with emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

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

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

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

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

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

Workload layer 90 provides an example of the functionality that may utilize a cloud computing environment. Examples of workloads and functions that may be provided from this layer include: map and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; a transaction 95; and advanced page management 96.

Turning now to fig. 19, a system 1900 is depicted in accordance with one or more embodiments of the invention. The system 1900 includes an example node 10 (e.g., a hosting node) in direct or indirect communication with one or more client devices 20A-20E, e.g., via the network 165. The node 10 may be a data center or a host server of a cloud computing provider. The node 10 executes a virtual machine monitor 12 that facilitates the deployment of one or more VMs 15 (15A-15N). The node 10 further includes a hardware/firmware layer 11, the hardware/firmware layer 11 providing direct support for functions required by the virtual machines 15A-N and the virtual machine monitor 12 and helping the virtual machine monitor 12 to provide one or more services to the virtual machine 15. In contemporary implementations, communication between the hardware/firmware layer 11 and the virtual machine monitor 12, between the hardware/firmware layer 11 and the virtual machine 15, between the virtual machine monitor 12 and the virtual machine 15, and between the virtual machine monitor 12 and the virtual machine through the hardware/firmware layer 11 is provided. According to one or more embodiments of the present invention, secure interface controls are provided in the hardware/firmware layer 11 and direct communication between the virtual machine monitor 12 and the virtual machine 15 is eliminated.

For example, the node 10 may facilitate the client device 20A to deploy one or more of the virtual machines 15A-15N. The virtual machines 15A-15N may be deployed in response to respective requests from different client devices 20A-20E. For example, VM 15A may be deployed by client device 20A, VM15B may be deployed by client device 20B, and VM 15C may be deployed by client device 20C. The node 10 may also facilitate client-side provisioning of physical servers (rather than running as VMs). The examples described herein embody provisioning of resources in the node 10 as part of a VM, however, the described solutions may also be applied to provisioning resources as part of a physical server.

In an example, the client devices 20A-20E may belong to the same entity, such as an individual, a business, a government agency, a department within a company, or any other entity, and the node 10 may operate as a private cloud of entities. In this case, the node 10 hosts only the virtual machines 15A-15N deployed by the client devices 20A-20E belonging to the entity. In another example, client devices 20A-20E may belong to different entities. For example, a first entity may own client device 20A, while a second entity may own client device 20B. In this case, the node 10 may be operated as a public cloud hosting VMs from different entities. For example, virtual machines 15A-15N may be deployed in a masked manner in which VM 15A does not facilitate access to VM 15B. For example, the node 10 may use IBM zProcessor resource/system manager (PR/SM) Logical Partition (LPAR) features to overlay virtual machines 15A-15N. These features (such as PR/SM LPAR) provide isolation between partitions, thus facilitating node 10 deploying two or more virtual machines 15A-15N in different logical partitions for different entities on the same physical node 10.

The client device 20A from the client devices 20A-20e is a communication device such as a computer, smartphone, tablet, desktop computer, laptop computer, server computer, or any other communication device requesting deployment of a VM by the virtual machine monitor 12 of the node 10. Client device 20A may send a request via network 165 that is received by the virtual machine monitor. VM 15A of virtual machines 15A-15N is a VM image that is deployed by virtual machine monitor 12 in response to a request by a client device 20A of client devices 20A-20 e. The virtual machine monitor 12 is a VM monitor (VMM), which may be software, firmware, or hardware that creates and runs VMs. The virtual machine monitor 12 facilitates the execution of programs and/or the storage of data by the VM 15A using hardware components of the node 10. With appropriate features and modifications, the virtual machine monitor 12 may beVM Server from Oracle, XenServer from Citrixgoon, ESX from Vmware, Hyper-V hypervisor from Microsoft, or any other virtual machine monitor. The virtual machine monitor 12 may be a native virtual machine monitor executing directly on the node 10, or a hosted virtual machine monitor executing on another virtual machine monitor.

Turning now to fig. 20, a node 10 for implementing the teachings herein is shown in accordance with one or more embodiments of the present invention. Node 10 may be an electronic computer framework including and/or employing any number and combination of computing devices and networks utilizing different communication technologies as described herein. The node 10 can be easily scalable, extensible, and modular, with the ability to change to different services or reconfigure some features independently of other nodes.

In the present embodiment, the node 10 has a processor 2001, and the processor 2001 may include one or more Central Processing Units (CPUs) 2001a, 2001b, 2001c, and the like. A processor 2001 (also known 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 Read Only Memory (ROM)2004 and Random Access Memory (RAM) 2005. ROM 2004 is coupled to system bus 2002 and may include a basic input/output system (BIOS), which controls certain basic functions of node 10. The RAM is read and write memory coupled to the system bus 2002 for use by the processor 2001.

The node 10 of fig. 20 includes a hard disk 2007, which is an example of a tangible storage medium readable by the processor 2001. The hard disk 2007 stores software 2008 and data 2009. Software 2008 is stored as instructions executed by processor 2001 on node 10 (to perform processes, such as those described with reference to fig. 1-19). Data 2009 includes a set of values organized in different data structures to support the operation of software 2008 and qualitative or quantitative variables used by the operation of software 2008.

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

as shown, node 10 includes an interface adapter 2020 that interconnects a keyboard 2021, mouse 2022, speaker 2023, and microphone 2024 to system bus 2002. The node 10 includes a display adapter 2030 interconnecting the system bus 2002 to a display 2031. Display adapter 2030 (and/or processor 2001) may include a graphics controller to provide graphics capabilities such as display and management of GUI 2032. Communications adapters 2041 interconnect the system bus 2002 with the network 2050, enabling the node 10 to communicate with other systems, devices, data, and software, such as servers 2051 and databases 2052. In one or more embodiments of the invention, the operations of software 2008 and data 2009 may be implemented by a server 2051 and a database 2052 over a network 2050. For example, network 2050, servers 2051, and databases 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 web application in a distributed system).

The embodiments described herein are necessarily rooted in computer technology, and in particular, in computer servers hosting VMs. Further, one or more embodiments of the present invention facilitate improvements to the operation of the computing technology itself (particularly, the computer server hosting the VM) by facilitating the hosting of the secure VM by the computer server hosting the VM, wherein even the virtual machine monitor is prohibited from accessing memory, registers, and other such data associated with the secure VM. Furthermore, one or more embodiments of the present invention provide an important step for improving VM hosting compute servers by using a secure interface control (also referred to herein as "UV") comprising hardware, firmware (e.g., millicode), or a combination thereof, to facilitate separation of secure VMs and virtual machine monitors, and thus maintain security of VMs hosted by the compute servers. The secure interface control provides lightweight intermediate operations to facilitate security without adding significant overhead to secure VM state during initialization/exit of the VM as described herein.

Embodiments of the invention disclosed herein may include systems, methods, and/or computer program products (herein, systems) for implementing secure interface control advanced page management. Note that for each interpretation, the identifiers of the elements are repeated for other similar elements of different figures.

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

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

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

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

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

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

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

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

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

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

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

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

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that 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 preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the embodiments in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen and described in order to best explain various aspects and practical applications, to enable others of ordinary skill in the art to understand the embodiments for various modifications as are suited to the particular use contemplated.