Secure Paging with Page Change Detection

Abstract

According to one or more embodiments of the present invention, a computer-implemented method includes computing a hash value of a memory page of a computer system and comparing the hash value with a previously computed hash value of the page. Based on determining that the hash value matches the previously computed hash value, the page can be encrypted with a per-page per-encryption value. Based on determining that the hash value does not match the previously computed hash value, the page can be encrypted with a modified value of the per-page per-encryption value.

Description

Background Art

[0001] The present invention generally relates to computer technology, and more particularly to secure paging with page change detection.

[0002] Cloud computing and cloud storage provide users with the ability to store and process their data in a third-party data center. Cloud computing facilitates the ability to quickly and easily provision VMs to clients without the clients having to purchase hardware or provide floor space for physical servers. Clients can easily scale or shrink VMs according to the clients' changing preferences or requirements. Generally, cloud computing providers provide VMs that physically reside on servers at the provider's data center. Customers typically care about the security of the data in the VMs, especially since computing providers often store data for more than one client on the same server. A client may expect security between their own code / data and the code / data of the cloud computing provider, as well as between their own code / data and the code / data of other VMs running at the provider's site. In addition, a customer may expect security from the provider's administrators and protection against potential security vulnerabilities from other code running on the machine.

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

[0004] Generally, a VM running as a guest under the control of a host hypervisor depends on the hypervisor to transparently provide virtualization services for the guest. These services include memory management, instruction emulation, and interrupt handling.

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

[0006] According to one or more embodiments of the present invention, a computer-implemented method includes: calculating a hash value of a memory page of a computer system and comparing the hash value with a previously calculated hash value of the page. Based on determining that the hash value matches the previously calculated hash value, the page can be encrypted with a per-encryption value per page. Based on determining that the hash value does not match the previously calculated hash value, the page can be encrypted with a modified value of the per-encryption value per page. Advantages can include enhanced encryption by introducing the per-encryption value while limiting encryption updates when the underlying data has not changed.

[0007] According to additional or alternative embodiments of the present invention, the encryption can be performed by a security control interface in response to a request from the host to convert the page from a secure page to a non-secure page. Advantages can include preventing direct access to the underlying data by encrypting before making the page non-secure and accessible by an untrusted entity.

[0008] According to additional or alternative embodiments of the present invention, the encrypted non-secure page can be provided to the host for storage. Advantages can include implementing memory management for input / output access and movement of memory pages by potentially untrusted entities.

[0009] According to additional or alternative embodiments of the present invention, the hash value can be stored in a security table of the security control interface. Advantages can include saving a summary value for change comparison.

[0010] According to additional or alternative embodiments of the present invention, the non-secure page can be converted into the secure page. The secure interface control can decrypt the page based on each encryption value associated with the secure page to generate a decrypted page. A hash value of the decrypted page can be calculated. The hash value of the decrypted page can be compared with the hash value of the page stored in the secure table. The decrypted page is verified based on determining that the hash value of the decrypted page matches the hash value stored in the secure table. Advantages can include verifying that a page provided to an untrusted entity has not been modified.

[0011] According to additional or alternative embodiments of the present invention, the secure interface control can include firmware, hardware, or a combination of firmware and hardware. The secure page can be assigned to a secure container or a secure virtual machine managed by the host. The host can be a hypervisor or an operating system. Advantages can include sharing secure pages from a secure entity with an untrusted entity using encryption.

[0012] According to additional or alternative embodiments of the present invention, encrypting the page can embody using a cryptographic secure hash function on a combination of an address value associated with the page, one or more random values, and each encryption value. Advantages can include increasing the complexity of encryption to enhance security.

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

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

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

[0016] Figure 1 A partitioned secure table according to one or more embodiments of the present invention is depicted;

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

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

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

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

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

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

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

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

[0025] Figure 10 Depicts a process flow of the conversion from a non-secure hypervisor page to a secure page of a secure interface control according to one or more embodiments of the present invention;

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

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

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

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

[0030] Figure 15 Shows a process flow for determining whether page content has changed before encryption according to one or more embodiments of the present invention;

[0031] Figure 16 Depicts a data flow for encryption and decryption control by a secure interface control according to one or more embodiments of the present invention;

[0032] Figure 17 illustrates a cloud computing environment in accordance with one or more embodiments of the present invention;

[0033] Figure 18 depicts an abstract model layer in accordance with one or more embodiments of the present invention;

[0034] Figure 19 depicts a system in accordance with one or more embodiments of the present invention; and

[0035] Figure 20 depicts a processing system in accordance with one or more embodiments of the present invention.

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

[0037] One or more embodiments of the present invention use a counter to perform encryption of memory pages, the counter modifying the encryption process based on whether a change in underlying data is detected. Secure storage may be managed to ensure that data pages within a secure domain are inaccessible to non-secure entities. When data in a secure domain is transmitted to a non-secure domain (such as for storage to disk), the data may be encrypted before being transmitted to the non-secure domain. To enhance security, when encrypting a data page, multiple items may be combined into an initialization vector, such as a counter value that is incremented when a data change is detected. Thus, if the data page remains unchanged, the encryption will match other previous copies of the encrypted data, thereby preserving existing paging algorithms. However, if the underlying data has changed, the per-encryption value of the per-encryption counter may be modified and used as part of the encryption process. Introducing the per-encryption value makes it more difficult to detect patterns in the encrypted data, as the encryption changes based on a combination of data value changes and per-encryption value changes. The combination of the per-encryption counter and page change detection may support multiple reuses of paged-out encrypted content as long as the underlying content remains unchanged, which can be useful for increasing the efficiency of a processing system for read-only memory pages. Conversely, if page change detection is not used and the per-encryption counter is modified, for example, every time a page is accessed, the paged-out page cannot be reused multiple times even if the underlying data has not changed.

[0038] Embodiments of the present invention are described with reference to paging that supports virtual machines, containers, hypervisors, operating systems, and other computer system elements. It will be understood that the processes described herein are applicable to numerous system configurations and are not limited to the example systems described in more detail herein.

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

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

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

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

[0043] In one example, the secure interface control is implemented in internal, secure, and trusted hardware and / or firmware. The trusted firmware can include, for example, processor millicode or PR / SM logical partition code. For a secure client or entity, the secure interface control provides initialization and maintenance of the secure environment and coordinates the dispatch of these secure entities on the hardware. When a secure client actively uses data and it resides in host storage, it remains "in the clear" in secure storage. Secure client storage can be accessed by that single secure client - this is strictly enforced by the hardware. That is, the hardware prevents any non-secure entity (including the virtual machine monitor or other non-secure clients) or different secure clients from accessing the data. In this example, the secure interface control runs as the lowest-level trusted part of the firmware. The lowest level or millicode is effectively an extension of the hardware and is used to implement complex instructions and functions defined, for example, in IBM's. The millicode can access all parts of storage, which, in the context of secure execution, includes its own secure UV storage, non-secure virtual machine monitor storage, secure client storage, and shared storage. This allows it to provide any functions required by the secure client or that the virtual machine monitor needs 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 conditions established by the secure interface control.

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

[0045] These UVC commands can be executed by machine firmware similarly to many other architected instructions. The machine does not enter the secure interface control mode, but instead executes the secure interface control functions in the mode it is currently running in. The hardware maintains both the firmware state and the software state, so these operations can be processed without a context switch. This low overhead allows different layers of software, trusted firmware, and hardware to tightly bind and cooperate in a way that minimizes and reduces the complexity of the secure interface control while still providing the necessary level of security.

[0046] According to one or more embodiments of the present invention, to support the control block structures required by the secure interface control and the hardware to properly maintain the secure guest and support the hypervisor environment, the hypervisor donates storage to the secure interface control while initializing the secure guest environment. Thus, to prepare for 1) initializing the zone in which the secure guest runs, 2) creating a secure guest domain, and 3) creating secure CPUs that run in each domain, the hypervisor issues query UVC instructions to determine the amount of storage required for donation, etc. Once the storage has been donated, it is marked as secure and registered as belonging to the secure interface control; and, any access by non-secure or secure guest entities is prohibited. This remains the case until the relevant entities (e.g., secure guest CPU, secure guest domain, or zone) are disassembled.

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

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

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

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

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

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

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

[0054] Dynamic address translation (DAT) is used to map virtual storage to physical storage. When a guest VM runs as a paged guest under the control of the hypervisor, the guest uses DAT to manage the pages resident in its memory. Additionally, when the pages are resident in its memory, the host independently uses DAT to manage those guest pages (along with its own pages). The hypervisor uses DAT to provide isolation and / or sharing of storage between different VMs and to prevent guests from accessing hypervisor storage. When a guest runs in non-secure mode, the hypervisor can access all guest storage.

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

[0056] DAT uses multi-table lookups to convert a virtual address into an associated absolute address. This table structure is typically defined and maintained by the storage manager. The storage manager transparently shares physical storage among multiple programs by paging out, for example, one page to bring in another page. When a page is paged out, the storage manager sets an invalid bit, for example, in the associated page table. When a program attempts to access a paged-out page, the hardware submits a program interrupt, often referred to as a page fault, to the storage manager. In response, the storage manager pages in the requested page and resets the invalid bit. This is all done transparently to the program and allows the storage manager to virtualize storage and share it among various different users.

[0057] When the CPU accesses the main memory using a virtual address, it first converts the virtual address into a real address through the DAT, and then converts it into an absolute address through prefixing. The designation (origin and length) of the top-level table for a specific address space is called the Address Space Control Element (ASCE) and defines the associated address space.

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

[0059] Now turn to Figure 3 , according to one or more embodiments of the present invention, an example for supporting nested multi-part DAT conversion for VMs running under a hypervisor is generally shown. In Figure 3In the example shown, both the virtual address space A302 of client A (defined by client ASCE (GASCE) A304) and the virtual address space B 306 of client B (defined by GASCEB 308) reside in the shared host (hypervisor) virtual address space 325. As shown, the virtual pages A1.GV 310a1, A2.GV 310a2, and A3.GV 310a3 belonging to client A are mapped by the storage manager of client A to client absolute pages A1.HV 340a1, A2.HV 340a2, and A3.HV 340a3 respectively using GASCEA304; the virtual pages B1.GV 320bl and B2.GV 320b2 belonging to client B are mapped by the storage manager of client B independently to client absolute pages B1.HV 360bl and B2.HV 360b2 using GASCEB 308. In this example, these client absolute pages are directly mapped into the shared host virtual address space 325 and subsequently undergo an additional host DAT translation to the host absolute address space 330. As shown, the host virtual addresses A1.HV 340a1, A3.HV 340a3, and B1.HV 360b1 are mapped by the host storage manager using host ASCE (HASCE) 350 to A1.HA 370a1, A3.HA 370a3, and B1.HA 370b1. Both the host virtual address A2.HV 340a2 belonging to client A and B2.HV 360b2 belonging to client 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 an additional nested host DAT translation.

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

[0061] According to one or more embodiments of the present invention, storage sharing between secure guests is also prohibited. Storage is shared between a single secure guest and a hypervisor controlled by that secure guest. The UV storage is secure storage and is a secure interface control rather than client / host accessible. The hypervisor allocates storage to the interface control. According to one or more embodiments of the present invention, the hardware and the secure interface control prohibit any attempt to violate these rules.

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

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

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

[0065] According to one or more embodiments of the present invention, when a non-secure guest or the hypervisor attempts to access a page owned by a secure guest, the hypervisor receives a secure-storage access (PIC3D) exception. This is determined without the need for additional translation steps.

[0066] According to one or more embodiments, when a secure entity attempts to access a page, the hardware performs an additional translation check to verify that the storage indeed belongs to a specific secure guest. If not, a non-secure access (PIC3E) exception is submitted to the hypervisor. Additionally, if the translated host virtual address does not match the host virtual address of the registered host-address pair in the partition security table, a secure storage violation (‘3F’x) exception is identified. To enable sharing with the hypervisor, a secure guest can access non-securely stored pages as long as the translation check allows access.

[0067] Now turning to Figure 5 , a system schematic diagram 500 of DAT operations in accordance with one or more embodiments of the present invention is generally shown. System schematic diagram 500 includes a host primary virtual address space 510 and a host home virtual address space 520 in which pages are translated (e.g., see host DAT translation 525; note that the dashed lines represent the mapping through DAT translation 525) to the hypervisor (host) absolute address space 530. For example, Figure 5Shows the sharing of host absolute storage by two different host virtual address spaces, and also shows the sharing of one of those host virtual addresses not only between two clients, but also additionally with the host itself. In this regard, the host base virtual address space 510 and the host home virtual address space 520 are instances of two host virtual address spaces, each of which is addressed by a separate ASCE - host base ASCE (HPASCE) 591 and host home ASCE (HHASCE) 592 respectively. Note that all security interface control storage (virtual and physical) is donated by the hypervisor and marked as secure. Once donated, the security interface control storage can only be accessed by the security interface control as long as the associated security entity exists.

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

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

[0070] Thus, in the case of "client absolute = host virtual", the hypervisor (host) main DAT table (defined by HPASCE 591) translates the pages of the host base virtual address space 510 as follows: The client A absolute page A1.HV is mapped to the host absolute page A1.HA belonging to the secure client A; the client A absolute page A2.HV is mapped to the host absolute page A2.HA belonging to the secure client A; the client B absolute page B1.HV is mapped to the host absolute page B1.HA belonging to the secure client B; the host virtual page H3.HV is mapped to the host absolute page H3.HA non-secure host (no host-address pair because it is non-secure). Further, the hypervisor (host) main DAT table (defined by HHASCE 592) translates the pages of the host home virtual address space 520 as follows: The secure interface control virtual page U1.HV is mapped to the host absolute page U1.HA defined as secure UV virtual; the host virtual page H1.HV is mapped to the host absolute page H1.HA defined as non-secure; the host virtual page H2.HV is mapped to the host absolute page H2.HA defined as non-secure. There are no host-address pairs associated with H1.HA or H2.HA because they are non-secure.

[0071] In operation, if a secure client attempts to access a secure page allocated to the secure interface control, the hardware submits a secure store violation ('3F'X) exception to the hypervisor. If a non-secure client or the hypervisor attempts to access any secure page (including those allocated to the secure interface control), the hardware submits a secure store access ('3D'X) exception to the hypervisor. Alternatively, an error condition can be submitted for an attempted access to the secure interface control space. If the hardware detects a mismatch in the secure allocation for a secure interface control access (e.g., stored in the partition security table as belonging to a secure client rather than to the secure interface control, or the host-address pair in use does not match the registered pair), a check is submitted.

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

[0073] An instance of the transformed hypervisor (host) absolute address space 530 is visible in Figure 6 . Figure 6 is a system diagram 600 depicting the secure interface control memory in accordance with one or more embodiments of the present invention. The system diagram 600 shows a hypervisor (host) absolute address space 630, which includes a host absolute page A2.HA for secure guest A (for A2.HV); a host absolute page B1.HA for secure guest B (for B1.HV); a host absolute page H1.HA non-secure (host); a host absolute page H2.HA non-secure (host); a host absolute page U3.HA secure UV real (no HV mapping); a host absolute page U1.HA secure UV virtual (for U1.HV); and a host absolute page A1.HA for secure guest A (for A1.HV).

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

[0075] Then at block 730, the host absolute page is mapped in the appropriate (host virtual address-based) host DAT table. At block 735, the hypervisor host then reschedules the secure guest. At block 740, the secure guest re-accesses the guest secure page. The page fault no longer exists, but since this is a secure guest access and the page is not marked as secure in the partitioned security table 100 of FIG. 100, at block 745, the hardware submits a non-secure store exception (PIC3E) to the hypervisor. This PIC3E blocks the guest's access to this secure page until the necessary import has been issued. Next, the process flow 700 proceeds to the continuation of Figure 8 "A".

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

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

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

[0079] If the host virtual page to be imported is not shared with the hypervisor (process flow 800 advances to block 840), then the security interface control marks the page as secure so that the hypervisor can no longer access the page. At block 845, the security interface control locks the page so that no other UVC can modify the page state. Once the lock is set (at block 850), the security interface control verifies that the content of the guest page has not changed during its encryption. If the content of the guest page has indeed changed, an error return code is returned to the hypervisor; otherwise, the security interface control decrypts the secure page.

[0080] 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 associates it with the appropriate guest domain and host virtual address to complete the host-address HV->HA pair. This allows the guest to access and completes the UVC.

[0081] Now turning to Figure 9 , in accordance with one or more embodiments of the present invention, a process flow 900 regarding donation memory operations is generally shown. Process flow 900 begins at block 905, where the hypervisor issues a query UVC to the security interface control. At block 910, the security interface control returns data (e.g., the query UVC). This data can include the amount of host-absolute storage required for a particular base partition; the amount of host-absolute storage required for a particular base secure-guest-domain; the amount of host-virtual storage required per MB for a variable secure-guest-domain; and / or the amount of host-absolute storage required for a particular base secure-guest-CPU.

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

[0083] At block 925, the security interface control implements the initialization (e.g., the initialization UVC) by registering the donated storage with the UV and marking it as secure. To implement the initialization UVC, the security interface control can mark the donated storage as secure; allocate some of the donated storage for the partition security table; and register the donated storage with the uniqueness security-domain for use by the UV in the partition security table, but not with the associated secure-guest-domain, and register it as not having an associated host-virtual address pair.

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

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

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

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

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

[0089] At arrow 1025, a create-SG-config or create-SG-CPU UVC is issued from the hypervisor (non-secure) page B, which converts the page to a secure interface control real storage 1030 associated with the secure guest domain (UVS). The secure interface control real storage 1030 can be marked as secure and registered in the partition security table (e.g., the partition security table 100 shown in Figure 1 as a UV with an associated secure guest domain and no hypervisor-to-host absolute mapping (HV->HA) (i.e., DA bit = 1). Note that the secure interface control real storage 1010 can be accessed by the secure interface control as a real on behalf of the secure guest domain.

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

[0091] Now turning to Figure 11 , according to one or more embodiments, a process flow 1100 regarding secure storage access by a program or secure interface control is shown. This represents a situation where the secure interface control is about to access client storage or secure interface control storage and must correctly label the access to allow the hardware to verify the security of the access. The process flow 1100 depicts such labeling of the storage access to the secure interface control. The process flow 1100 begins at block 1110, where the secure interface control determines whether it is accessing secure interface control storage.

[0092] If this is not an access to secure interface control storage, the process flow 1100 advances to decision block 1112 (as shown by the "No" arrow). At decision block 1112, the secure interface control determines whether it is accessing secure client storage. If this is not an access to secure client storage, the process flow 1100 advances to "B" (which is connected to the Figure 12 process flow 1200), which will use the default settings for secure client access. If this is an access to secure client storage, the process flow 1100 advances to decision block 1113, where the secure interface control determines whether the default secure guest domain is being used. If so, the process flow 1100 advances to "B" (which is connected toFigure 12 process flow 1200), 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-Security-Domain register (and proceeds to "B", which is connected to Figure 12 process flow 1200).

[0093] If this is an access to the secure interface control store, then process flow 1100 proceeds to box 1120 (as indicated by the "yes" arrow). At box 1120, the access is marked as secure UV (e.g., using the UV-Security-Domain register).

[0094] Process flow 1100 then proceeds to decision box 1130, where the secure interface control determines whether this is an access to the UVV space (e.g., the SG-Config Variable Table). If it is an access to the UVV space, then process flow 1100 proceeds to box 1134 (as indicated by the "yes" arrow). At box 1134, the access is marked as virtual. At box 1136, the applicable secure client domain is loaded into the UV-Security-Domain register. At box 1138, the DAT conversion and access store are ready to begin. Returning to decision box 1130, if this is not an access to the UVV space, then process flow 1100 proceeds to box 1140 (as indicated by the "no" arrow). At box 1140, the access is marked as real.

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

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

[0097] Figure 13Depicts an example of a hardware - implemented transformation for supporting both secure and non - secure accesses in process flow 1300 according to one or more embodiments of the present invention. At block 1305, the hardware can determine whether the access is marked as a client transformation. If so, and if at block 1310 it is determined that the access is virtual, then client DAT can be performed at block 1315. During client DAT transformation, there can be nested, intermediate fetches for guest DAT tables. If the original transformation is marked as secure, then table fetches can be marked as client real and secure. Table fetches can also follow the transformation process of process flow 1300. After performing client DAT for any access marked as client virtual at block 1315 and for any access marked as client real at block 1310 (virtual = no), client prefixes and client memory offsets can be applied at block 1320. When the client transformation process is complete, at block 1325, if the original client transformation is marked as secure, the resulting address can be marked as host virtual and marked as secure. Process 1300 can continue as for any access marked as host virtual. If at block 1305 it is determined that the original access is a host access (client = no) and at block 1330 it is determined to be marked as virtual, then host DAT can be performed at block 1335. At block 1335, host table fetches can be marked as non - secure. After performing host DAT at block 1335, or if at block 1330 it is determined that the original host access is marked as real (virtual = no), then host prefixes can be applied at block 1340. At block 1345, the resulting address can be a host absolute address.

[0098] Figure 14 Depicts an example of a DAT transformation with secure storage protection that can be performed by hardware in process flow 1400. From Figure 13If the access continues from block 1345 and secure-UV access is recognized at block 1405, the hardware can verify at block 1410 whether the storage is registered as a secure-UV storage, and if not, submit an error at block 1415. When accessing the UV storage, the secure interface control can perform secure-UV access. If it is determined at block 1410 that the storage is registered as a secure-UV storage, protection checks can continue as for any secure access, except that at block 1420 (where the process continues), the UV-secure-domain register (set by the secure interface control before performing the secure UV access) can be used as the designated secure domain for domain checks. Additionally, any violation detected at block 1425 for the UV access (entry point D) can be submitted as an error at block 1430, rather than submitting an exception to the hypervisor at block 1435 as is done for a secure client violation (secure-UV = no) at block 1425.

[0099] For an access not marked as secure-UV access at block 1405, at block 1440, the hardware determines whether the access is a secure client access, and if not and if the page is marked as secure at block 1445, an exception can be submitted to the hypervisor 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 conversion is successful at block 1450.

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

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

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

[0103] Now turning to Figure 15 , in accordance with one or more embodiments of the present invention, a process flow 1500 for determining whether page content has changed prior to encryption is generally shown. Refer to Figure 16The data stream 1600 further describes the process flow 1500. At block 1505, the process flow 1500 begins. At block 1510, a hash value of a secure page of memory of the computer system is calculated. For example, a secure interface control 1605 that may be part of the computer system may calculate a hash function of the secure page 1610 in the secure domain 1615 before the content of the secure page 1610 is provided as an insecure page 1620 in the insecure domain 1625 (i.e., accessible but encrypted). The hash function of block 1510 may be in the form of a checksum that supports detection of changes in one or more data bits of the secure page 1610. The secure page 1610 cannot be directly accessed by an insecure entity such as an insecure hypervisor or operating system. The insecure page 1620 may be used by different processes such as Figure 7 block 725 of process flow 700. Encryption and decryption may be managed by the encryption / decryption control 1630 of the secure interface control 1605. Encryption and decryption may also be invoked as part of various processes such as Figure 8 process flow 800. The secure interface control 1605 may include firmware, hardware, or a combination of firmware and hardware. For example, the secure interface control 1605 may be part of a processing unit (e.g., the processing circuitry of a computer processor) or callable by the processing unit. The secure page 1610 may be assigned to a secure container or secure virtual machine managed by a host, where the host is, for example, a hypervisor or an operating system.

[0104] At block 1515 of the process flow 1500, the hash value calculated at block 1510 may be compared with a previously calculated hash value of the page. For example, a security table 1635 of the secure interface control 1605 may store multiple page identifiers 1640 and hash values 1645 of associated pages. When calculating the hash value of the secure page 1610, the secure interface control 1605 may perform a lookup of the associated address in the page identifiers 1640 to determine whether the hash value 1645 includes the previously calculated hash value of the secure page 1610.

[0105] At block 1520, based on determining that the hash value does not match the previously computed hash value for the same page, the modified value of the per-encryption value per page can be used to encrypt the page at block 1525. At block 1525, based on determining that the hash value matches the previously computed hash value for the same page, the per-encryption value of the per-encryption counter 1650 can be used without modification / increment when encrypting the page. The value of the per-encryption counter 1650 can be managed on a per-page basis. The initial value of the per-encryption counter 1650 can be established before using the per-encryption value and referencing the associated page. The per-encryption counter 1650 can be used by the encryption / decryption control 1630, for example, as part of encryption or decryption to further randomize the relationship between the encryption value and the decryption value. As an example, encrypting a page can include combining the address value associated with the page, one or more random values, and the per-encryption value with a cryptographically secure hash function. By modifying the per-encryption value only when the underlying data changes, the encryption of the resulting unchanged data can be aligned with a copy of the previously encrypted same data. Even if a non-secure entity such as a hypervisor or an operating system may not understand the encrypted content of the non-secure page 1620, identifying the unchanged state can achieve more efficient memory management by avoiding making further copies of the encrypted data of the unchanged page and / or preventing updates to the unchanged page. At block 1530, the process flow 1500 ends.

[0106] In an embodiment of the present invention, encryption may be performed by the encryption / decryption control 1630 of the security control interface 1605 in response to a request from a host (e.g., a hypervisor or an operating system) to convert a page from a secure page 1610 to an insecure page 1620. For example, as part of a memory management operation, an encrypted insecure page 1620 may be provided to the host for storage. The computed hash value may be stored in the hash value 1645 of the security table 1635 of the security control interface 1605. During a subsequent operation, the security control interface 1605 may convert the insecure page 1620 to a secure page 1610, and the encryption / decryption control 1630 may decrypt the secure page 1610 based on the per-encryption value associated with the page to produce a decrypted page. The security interface control 1605 may compute the hash value of the decrypted page and compare the hash value of the decrypted page with the hash value 1645 stored in the security table 1635. The decrypted page may be verified based on determining that the hash value of the decrypted page matches one of the hash values 1645 stored in the security table 1635, and the verified and decrypted page may be made available for use as a secure page 1610 in the secure domain 1615. This verification may confirm that the insecure page 1620 has not been modified (e.g., cached to disk and retrieved) while in the insecure domain 1625. The page conversion between secure and insecure may include setting a bit or a label associated with the page to restrict the accessibility of the page.

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

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

[0109] The characteristics are as follows:

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

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

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

[0113] Rapid elasticity: Capabilities can be configured quickly and elastically, automatically scaling out rapidly in some cases and releasing quickly to scale in. To the consumer, the capabilities available for configuration often appear limitless and can be purchased in any quantity at any time.

[0114] Measured service: The cloud system automatically controls and optimizes resource use by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized services.

[0115] The service models are as follows:

[0116] Software as a Service (SaaS): The capabilities provided to the consumer are the use of the provider's applications running on a cloud infrastructure. These applications can be accessed from different client devices via a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

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

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

[0119] The deployment models are as follows:

[0120] Private Cloud: The cloud infrastructure is for the exclusive use of an organization's operations. It can be managed by the organization or a third party and can exist either on-premises or off-premises.

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

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

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

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

[0125] Now refer to Figure 17 , which depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 52, and local computing devices used by cloud consumers (such as a personal digital assistant (PDA) or cellular phone 54A, desktop computer 54B, laptop computer 54C, and / or in-vehicle computer system 54N) can communicate with the cloud computing nodes 52. The nodes 52 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as in the private cloud, community cloud, public cloud, or hybrid cloud or a combination thereof as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, and cloud consumers do not need to maintain resources on their local computing devices. It should be understood that Figure 17 the types of computing devices 54A-N shown in

[0126] Now refer to Figure 18 , which shows a set of functional abstraction layers provided by the cloud computing environment 50 ( Figure 17 ). It should be understood in advance that Figure 18 the components, layers, and functions shown in

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

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

[0129] In one example, the management layer 80 can provide the functions described below. Resource provisioning 81 provides for the dynamic acquisition of computing resources and other resources for performing tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources can include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for 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 levels are met. Service level agreement (SLA) planning and fulfillment 85 provides for the pre-arrangement and procurement of cloud computing resources for future requirements of cloud computing resources as expected under the SLA.

[0130] The workload layer 90 provides examples of functions that can utilize the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: maps and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and controlling access to secure storage of virtual machines 96.

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

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

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

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

[0135] Now turning to Figure 20 , according to one or more embodiments of the present invention, node 10 for implementing the teachings herein is shown. Node 10 can be an electronic computer framework including and / or employing any number of computing devices and networks and their combinations using different communication technologies as described herein. Node 10 can be easily upgradeable, scalable and modular, with the ability to change to different services or reconfigure some features independently of other nodes.

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

[0137] Figure 20 Node 10 of [description] includes a hard disk 2007, which is an example of a readable tangible storage medium executable by the processor 2001. The hard disk 2007 stores software 2008 and data 2009. The software 2008 is stored as instructions to be executed by the processor 2001 on node 10 (to perform a process, for example, see the process described in Figure 1-19 [description]. The data 2009 includes a set of values of qualitative or quantitative variables organized in different data structures to support the operation of the software 2008 and used by the operation of the software 2008.

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

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

[0140] 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 an improvement in the operation of computing technology itself (specifically, computer servers hosting VMs) by facilitating a computer server hosting a VM to host a secure VM, wherein even the hypervisor is prohibited from accessing the memory, registers, and other such data associated with the secure VM. Additionally, one or more embodiments of the present invention provide an important step for improving VM-hosting computing servers by using a security interface control (also referred to herein as "UV") that includes hardware, firmware (e.g., microcode), or a combination thereof to facilitate the separation of the secure VM and the hypervisor and, thus, maintain the security of the VMs hosted by the computing server. The security interface control provides lightweight intermediate operations to facilitate security without adding a large overhead to securing the VM state during VM initialization / exit as described herein.

[0141] Embodiments of the present invention disclosed herein may include systems, methods, and / or computer program products (herein, systems) for controlling access to secure storage of VMs. Note that for each illustration, the identifier of an element is reused for other similar elements in different figures.

[0142] Various embodiments of the present invention are described herein with reference to the related drawings. Alternative embodiments of the present invention may be designed without departing from the scope of the present invention. Various connection and positional relationships (e.g., above, below, adjacent, etc.) are set forth between elements in the description and the drawings. Unless otherwise specified, these connections and / or positional relationships may be direct or indirect, and the present invention is not limited in this regard by way of illustration. Thus, the coupling of entities may refer to direct or indirect coupling, and the positional relationship between entities may be direct or indirect positional relationship. In addition, the various tasks and process steps described herein may be incorporated into a more comprehensive program or process having additional steps or functions not detailed herein.

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

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

[0145] The terms "about", "substantially", "approximately" and their variants are intended to include the degree of error associated with the measurement of a specific quantity based on the 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.

[0146] The present invention may be a system, method, and / or computer program product at any possible level of integrated 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 execute aspects of the present invention.

[0147] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device (such as a punched card or raised structures in grooves having instructions recorded thereon), and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0148] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or an external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include a copper transmission cable, an optical transmission fiber, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

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

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

[0151] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine that, when executed by the processor of the computer or other programmable data processing device, creates a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing device, and / or other devices to act in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

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

[0153] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present technical solution. To this end, each block in the flowchart or block diagram may represent a module, segment, or portion of an instruction, which includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the blocks 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 on the functions involved. It will also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a system based on dedicated hardware that performs the specified functions or actions or a combination of dedicated hardware and computer instructions.

[0154] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that when the terms "comprises" and / or "comprising" are used in this specification, they specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0155] 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 forms 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 the various aspects and practical applications, such that those of ordinary skill in the art can understand the various embodiments with different modifications that are suitable for the particular purposes contemplated.

Claims

1. A computer-implemented method, comprising: Calculate the hash value of a memory page of a computer system; Compare the hash value with a previously calculated hash value of the page; Based on determining that the hash value matches the previously calculated hash value, encrypt the page with each encryption value of each page; and Based on determining that the hash value does not match the previously calculated hash value, encrypt the page with a modified value of each encryption value of each page.

2. The method according to claim 1, wherein, Execute the encryption by a security interface control in response to a request from a host to convert the page from a secure page to an insecure page.

3. The method according to claim 2, further comprising: Provide the encrypted insecure page to the host for storage.

4. The method according to claim 2, further comprising: Store the hash value in a security table of the security interface control.

5. The method according to claim 4, further comprising: Convert the insecure page to the secure page; Decrypt the secure page by the security interface control based on each encryption value associated with the secure page to generate a decrypted page; Calculate the hash value of the decrypted page; Compare the hash value of the decrypted page with the hash value of the page stored in the security table; and Verify the decrypted page based on determining that the hash value of the decrypted page matches the hash value stored in the security table.

6. The method according to claim 2, wherein, The security interface control includes firmware, hardware, or a combination of firmware and hardware; the secure page is assigned to a secure container or a secure virtual machine managed by the host; the host is a hypervisor or an operating system.

7. The method according to any one of claims 1 to 6, wherein, Encrypting the page embodies using a cryptographically secure hash function on a combination of an address value associated with the page, one or more random values, and each encryption value.

8. The method according to any one of claims 1 to 6, wherein, Establish an initial value of each encryption value before using each encryption value.

9. A computer system, comprising: Memory; Processing unit; and A security interface control, interfacing with the processing unit and the memory, the security interface control being configured to perform operations including the following: Calculate the hash value of a memory page; Compare the hash value with a previously calculated hash value of the page; Based on determining that the hash value matches the previously calculated hash value, encrypt the page with each encryption value of each page; and Based on determining that the hash value does not match the previously calculated hash value, encrypt the page with a modified value of each encryption value of each page.

10. The computer system according to claim 9, wherein, Execute the encryption by the security interface control in response to a request from a host to convert the page from a secure page to an insecure page.

11. The computer system according to claim 10, wherein, The operations further include providing the encrypted insecure page to the host for storage.

12. The computer system according to claim 10, wherein, The operations further include storing the hash value in a security table of the security interface control.

13. The computer system according to claim 12, wherein, The operations further include: Convert the insecure page to the secure page; Decrypt the secure page by the security interface control based on each encryption value associated with the secure page to generate a decrypted page; Calculate the hash value of the decrypted page; Compare the hash value of the decrypted page with the hash value of the page stored in the security table; and Verify the decrypted page based on determining that the hash value of the decrypted page matches the hash value stored in the security table.

14. The computer system according to claim 10, wherein, The security interface control includes firmware, hardware, or a combination of firmware and hardware; the secure page is assigned to a secure container or a secure virtual machine managed by the host; the host is a hypervisor or an operating system.

15. The computer system according to any one of claims 9 to 14, wherein, Encrypting the page involves using a cryptographic secure hash function on a combination of the address value associated with the page, one or more random values, and the per-encryption value.

16. The computer system according to any one of claims 9 to 14, wherein, The initial value of the per-encryption value is established before using the per-encryption value.

17. A computer program product, the computer program product comprising computer-executable instructions that, when executed, perform a method, the method comprising: Calculate the hash value of a memory page of a computer system; Compare the hash value with the previously calculated hash value of the page; Based on determining that the hash value matches the previously calculated hash value, encrypt the page with the per-encryption value of each page; and Based on determining that the hash value does not match the previously calculated hash value, encrypt the page with a modified value of the per-encryption value of each page.

18. The computer program product according to claim 17, wherein, The encryption is performed by the security interface control in response to a request from the host to convert the page from a secure page to a non-secure page.

19. The computer program product according to claim 18, wherein, When the executable instructions are executed, the method is further performed, including: Provide the encrypted non-secure page to the host for storage.

20. The computer program product according to claim 18, when the executable instructions are executed, further perform the method, comprising: Store the hash value in a security table of the security interface control.

21. The computer program product according to claim 20, wherein, When the executable instructions are executed, the method is further performed, including: Convert the non-secure page to the secure page; Decrypt the secure page by the security interface control based on the per-encryption value associated with the secure page to generate a decrypted page; Calculate the hash value of the decrypted page; Compare the hash value of the decrypted page with the hash value of the page stored in the security table; and Verify the decrypted page based on determining that the hash value of the decrypted page matches the hash value stored in the security table.

22. The computer program product according to claim 21, wherein, The secure page is assigned to a secure container or a secure virtual machine managed by the host, and the host is a hypervisor or an operating system.

23. The computer program product according to any one of claims 17 to 22, wherein, Encrypting the page involves using a cryptographic secure hash function on a combination of the address value associated with the page, one or more random values, and the per-encryption value.

24. The computer program product according to any one of claims 17 to 22, wherein, The initial value of the per-encryption value is established before using the per-encryption value.

Images