Security for Address Translation Services

Abstract

The processor receives a first request from a requester, the first request including a virtual address. Based on the first request, the processor determines a real address corresponding to the virtual address, encrypts at least a portion of the real address to obtain an encrypted secure real address, and returns the encrypted secure real address to the requester. Based on receiving a second request identifying the request address, the processor decrypts the request address and verifies the request address as the encrypted secure real address. Based on verifying the request address as the encrypted secure real address, the processor enables access to a resource of the data processing system identified by the real address.

Description

[Technical field]

[0001] The present invention relates generally to data processing, and more particularly to input / output (I / O) security in data processing systems.

[0002] A data processing system may include multiple processing elements and multiple Input / Output Adapters (IOAs) to support connections to communication networks, storage devices and / or storage networks, and peripheral devices. In such a data processing system, the hardware resources of the data processing system may be logically partitioned into multiple sets of resources, each controlled by a respective one of multiple, possibly heterogeneous, operating system instances. The operating systems execute simultaneously on this common hardware platform in their respective Logical Partitions (LPARs) under the control of system firmware commonly referred to as a Virtual Machine Monitor (VMM) or hypervisor. Thus, the hypervisor assigns a non-intersecting subset of the data processing system's resources to each LPAR, and each operating system instance in turn directly controls its separate set of allocatable resources, such as regions of system memory and IOAs.

[0003] Generally, IOAs in a data processing system employ an I / O (or virtual) address space that is separate from the real address space used to address system memory in the data processing system. As a result, address translation is employed to translate addresses between the I / O address space and the real address space of the data processing system. In at least some older prior art data processing systems, all translation between the I / O address space and the real address space was performed on the processor chip. As a result, the I / O to real address translation process could be used to restrict IOAs to only a subset of the real addresses that they were permitted to access.

[0004] More recently, at least some I / O standards, such as Peripheral Component Interconnect Express (PCIe), have introduced an Alternative Address Translation Service (ATS) where an IOA can request a translation for an I / O address and receive a corresponding real address from a host bridge in response. The IOA can then cache the real address in an Address Translation Cache (ATC) and subsequently issue one or more memory access requests to the host bridge that specify the real address. While improving latency for accesses that reference frequently or recently accessed addresses, allowing an IOA to make memory access requests using real addresses can expose host system memory to access by malicious or compromised I / O devices, thus raising significant security concerns. At least some prior art systems partially ameliorate this security concern by performing real address validation on incoming I / O memory access requests to ensure that each IOA accesses only authorized real address pages. However, this address translation service implementation has proven to be poorly performing and expensive to implement in terms of the memory footprint required to store the tables traditionally used to perform real address validation. These shortcomings are exacerbated in implementations where real address validation employs fine-grained validation based, for example, on both the Requestor Identifier (RID) and the Process Address Space Identifier (PASID). Summary of the Invention

[0005] In at least one embodiment, a data processing system provides enhanced I / O security while supporting address translation services for attached devices.

[0006] In various embodiments, the disclosed techniques may be implemented in a method, a data processing system, and / or a program product.

[0007] In at least one embodiment, a processor receives a first request from a requester, the requester including a virtual address. Based on the first request, the processor determines a real address corresponding to the virtual address, encrypts at least a portion of the real address to obtain an encrypted secure real address, and returns the encrypted secure real address to the requester. Based on receiving a second request identifying the request address, the processor decrypts the request address and verifies the request address as an encrypted secure real address. Based on verifying the request address as an encrypted secure real address, the processor enables access to a resource of the data processing system identified by the real address. The use of encrypted secure real addresses provides improved security and generally requires a smaller footprint to implement compared to table-based real address verification approaches.

[0008] In some embodiments, a requester may be an input / output (I / O) adapter. For example, in one particular embodiment, the adapter may communicate the request to the processor using the Peripheral Component Interconnect Express Address Translation Services (PCIe ATS) protocol. In other embodiments, a requester may be an attached device, such as an accelerator, that employs a virtual address space.

[0009] In some embodiments, at least a portion of the real address is encrypted using Advanced Encryption Standard (AES) based encryption. In some embodiments, encrypting at least a portion of the real address alternatively or additionally includes generating a hash of at least a portion of the real address. Using a strong encryption technique such as AES has the advantage of increased security, and using a hash has the advantage of high performance.

[0010] In some embodiments, the processor avoids encrypting the less significant bits of the real address that are used to identify an address within a memory page. By not encrypting the full real address (e.g., 64 bits), encryption is simplified and performance is improved.

[0011] In some embodiments, the encryption may be further strengthened by combining additional data with at least a portion of the real address prior to encryption. In some embodiments, the additional data may include bits from the requestor's process address space identifier and / or bits from a requestor identifier. In some embodiments, the additional data may alternatively or additionally include a read-only field indicating whether access to the real address by the requestor is read-only. In some embodiments, the additional data may include a key generation field that identifies which key from multiple keys was utilized to encrypt the real address. [Brief description of the drawings]

[0012] [Figure 1] 1 depicts a high-level block diagram of an exemplary data processing system, in accordance with one embodiment.

[0013] [Diagram 2] FIG. 2 is a more detailed block diagram of a host bridge and an I / O adapter (IOA) according to one embodiment.

[0014] [Diagram 3] 4 is a high-level logical flowchart of an exemplary process by which a processor provides an encrypted secure real address (sRA) to a requester in accordance with one embodiment.

[0015] [Figure 4] 4 is a high-level logical flowchart of an exemplary process by which a processor handles a memory access request from a requester, according to one embodiment.

[0016] [Figure 5A] 1 illustrates encryption of a real address to obtain a secure real address, and decryption of the secure real address to obtain the original real address, according to one embodiment. [Figure 5B] 1 illustrates encryption of a real address to obtain a secure real address, and decryption of the secure real address to obtain the original real address, according to one embodiment.

[0017] [Figure 6] 1 illustrates the contents of an exemplary host field of a real address, according to one embodiment.

[0018] [Figure 7] FIG. 2 is a high-level data flow diagram of an exemplary process for encrypting a real address to obtain an encrypted secure real address, according to one embodiment.

[0019] [Figure 8] FIG. 2 is a partial diagram illustrating a portion of the security logic of a processor that supports the use of key generation, according to one embodiment.

[0020] [Figure 9] 4 is a high-level logical flowchart of an exemplary process by which a processor implements key generation, according to one embodiment.

[0021] [Figure 10] FIG. 2 is a data flow diagram of an exemplary AES-based encryption process that may be utilized to generate a cryptographically secure real address, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Referring now to the figures, and in particular to Figure 1, there is depicted a high level block diagram of an exemplary data processing system 100 in accordance with one embodiment. In some embodiments, data processing system 100 may be a Symmetric MultiProcessor (SMP) system including, for example, multiple processors 102a-102n, each coupled for communication to a system fabric 104, which may include one or more bus or switch communication links. In alternative embodiments, a data processing system having a single processor 102 may be utilized.

[0023] In the illustrated embodiment, each processor 102 is preferably implemented as a single integrated circuit chip having a semiconductor substrate in which the integrated circuits are fabricated, as known in the art. As shown, each processor 102 includes multiple processor cores 110 that process data through the execution and / or processing of program code, which may include, for example, software and / or firmware and associated data, if applicable. This program code may include, for example, a hypervisor, one or more operating system instances to which the hypervisor may assign logical partitions (LPARs), and application programs. The processor 102 further includes a cache memory 112 that provides one or more levels of relatively low latency temporary storage for instructions and data retrieved from lower levels of a data storage hierarchy. In addition, the processor 102 includes an integrated memory controller (IMC) 114 that controls access to an associated one of the off-chip system memories 116a-116n. The processor 102 accesses the system memory 116 using real addresses (RAs) within a real address space. In various embodiments, the real address may have a different length, such as 32 bits, 64 bits, etc.

[0024] Each processor 102 further includes a Fabric Interface (FIF) 118 through which the processor 102 communicates with the system fabric 104, as well as one or more (and preferably multiple) Host Bridges (HBs) 120a-120k or 120m-120v that support input / output communication with various Input / Output Adapters (IOAs) 130a-130l or 130m-130w. The IOAs 130 may be, for example, network adapters, storage device controllers, display adapters, peripheral adapters, etc. In their operations, the IOAs 130 reference I / O addresses (also referred to as VAs) within a Virtual Address (VA) space. In various embodiments, the VAs may have different lengths, such as 32 bits, 40 bits, 48 ​​bits, 52 bits, 64 bits, etc. The length of the VA employed by the IOAs 130 may be different (i.e., shorter or longer) than the length of the RA employed by the processor 102.

[0025] In various embodiments, host bridge 120 may be communicatively coupled, directly or indirectly, to IOA 130. For example, in the illustrated embodiment, host buffers 120a, 120k, 120m, and 120v provide interfaces to local buses 122a, 122k, 122m, and 122v, respectively, to which IOA 130 may be directly connected or indirectly coupled. Thus, IOA 130a is optionally coupled to local bus 122a through I / O fabric 124a, which may comprise one or more switches and / or bridges. In a similar manner, IOAs 130k and 130l are optionally coupled to local bus 122k through I / O fabric 124k, IOA 130m is optionally coupled to local bus 122m through I / O fabric 124m, and IOAs 130v and 130w are optionally coupled to local bus 122v through I / O fabric 124v. In some embodiments, communications on one or more of local buses 122 utilize known I / O bus standards, such as the Peripheral Component Interconnect (PCI) or PCI Express (PCIe) standards. In some embodiments, one or more of local buses 122 may employ additional or alternative I / O bus standards.

[0026] 1, one or more of the processors 102 (e.g., processor 102a) may further include an Attached Device Interface (ADI) 140 that supports attachment of an attached device 142. In some embodiments, the attached device 142 may be an accelerator that allows the processor 102 to offload one or more processing functions, such as, for example, data encryption / decryption, data compression / decompression, matrix operations, data stream management, etc. In performing its processing, the attached device 142 may also reference a VA space that may be different or the same as that utilized by the IOA 130.

[0027] Those skilled in the art will appreciate that the architecture and components of the data processing system may vary between embodiments. For example, other devices and interconnections may be alternatively or additionally used. Thus, the exemplary data processing system 100 presented in FIG. 1 is not meant to suggest architectural limitations with respect to the claimed invention.

[0028] 2, a more detailed block diagram of host bridge 120 and I / O adapter 130 is illustrated according to one embodiment. In the illustrated example, host bridge 120 includes an I / O Memory Management Unit (IOMMU) 200 configured to provide a translation of a VA referenced by a requester, such as IOA 130, to an RA that may be utilized to access system memory 116 (and possibly other memory-mapped resources) of data processing system 100. Host bridge 120 additionally includes security logic 202 configured to encrypt addresses communicated to a requester and decrypt addresses received from a requester. In the illustrated embodiment, security logic 202 includes an Encryption Engine (EE) 204 for performing encryption to generate a secure real address (sRA), a decryption engine 206 for decrypting a request address received in a memory access request, and a key store 208 for storing keys utilized in encryption and decryption. In at least some embodiments, host bridge 120 may utilize a separate key for each requestor it supports. For example, assuming host bridge 120 is a PCIe host bridge, host bridge 120 may implement a respective key for each PCIe requestor identifier (RID) or for each combination of RID and process address space identifier (PASID). In at least some embodiments, security logic 202 additionally includes key generation logic 210 for generating cryptographic keys within key store 208, as well as optional real address validation (RAV) logic 212 for validating the real addresses of requests received by host bridge 120 from requestors.

[0029] 2 additionally illustrates that a requester, such as IOA 130, may include an address translation cache (ATC) 220. Address translation cache 220 may include multiple entries that associate recently and / or frequently accessed VAs with corresponding secure RAs (sRAs) received from host bridge 120.

[0030] 2, it should be understood that the ADI 140 of FIG. 1 may be constructed similarly to the host bridge 120. For example, the ADI 140 may include an IOMMU 200 and security logic 202. Similar to the IOA 130, the attached device 142 may also include an ATC 220 for caching VA to sRA translations obtained from the ADI 140.

[0031] 3, a high-level logic flow diagram of an exemplary process by which the processor 102 provides an encrypted secure RA (sRA) to a requester is shown, according to one embodiment. In some implementations, the process of FIG. 3 may be performed by the host bridge 120 to provide the encrypted sRA to the IOA 130. The same process may alternatively or additionally be employed by the ADI 140 to provide the sRA to the attached device 142.

[0032] The process of FIG. 3 begins at block 300 and then proceeds to block 302, which illustrates the processor 102 receiving a translation request from an associated requester that identifies a virtual address to be translated. In some embodiments, the translation request may be, for example, a PCIe ATS translation request. In response to receiving the translation request, the processor 102 translates the VA to an RA in the real address space of the data processing system 100, for example, utilizing the IOMMU 200. From block 304, the process proceeds to optional block 305, which illustrates the processor 102 preparing the RA for encryption. In the illustrated embodiment, preparing the RA for encryption in block 305 includes multiple steps including excluding from encryption a number of low-order bits of the RA that are utilized to identify a particular address within a given memory page (block 306). For example, assuming that the RA is 64 bits long and the processor 102 allocates a 2 MB memory page to a requester, 21 low-order bits of the RA are excluded from encryption in block 306. As will be appreciated, if the processor 102 avoids encrypting all bits of the RA, the encryption process is simplified and encryption performance is improved. At block 305, the truncated RA is optionally padded with a host field that includes one or more additional bits (block 308). Different embodiments of the host field are described below with reference to Figures 5A and 6. Additionally, at block 305, the processor 102 may shuffle the bits of the RA to generally increase the entropy (or randomness) of the bit values ​​(block 310). In a preferred embodiment, at block 310, the bit positions are rearranged within the intermediate RA in a fixed, predetermined manner.

[0033] From block 305, the process of FIG. 3 proceeds to block 312, which illustrates the processor 102 encrypting the RA (either the one received from the IOMMU 200 or, if block 305 is implemented, an intermediate RA obtained following block 305) to obtain an encrypted secure RA (sRA). In some embodiments, the encryption illustrated in block 312 may include the encryption engine 204 performing a hash of the RA. Suitable hash functions may include, for example, SHA-1, SHA-256, or MD-5. In other embodiments, the encryption may alternatively or additionally include the encryption engine 204 encrypting the RA using one or more keys. If key-based encryption is performed, it is preferred that the encryption engine 204 utilizes a different key for each requester (or for each combination of RID and PASID). Embodiments of possible encryption algorithms that may be employed are described below with reference to FIGS. 7 and 10. The processor then provides the sRA generated by the encryption performed in block 312 to the requester (block 314). In at least some embodiments, the processor 102 may communicate the sRA to the requester in a PCIe ATS translation response. In response to receiving the sRA, the requester may cache the VA to sRA translation (e.g., in the ATC 220) to facilitate future use of the sRA in memory access requests. Following block 314, processing of the translation request by the processor 102 ends at block 316.

[0034] 4, there is shown a high-level logical flow diagram of an exemplary process by which processor 102 handles a requester's memory access request, according to one embodiment. In some implementations, the process of FIG. 4 may be performed by host bridge 120 receiving a memory access request from IOA 130. The same process may alternatively or additionally be performed by ADI 140 in response to receiving a memory access request from attached device 142.

[0035] The process begins at block 400 and then proceeds to block 402, which illustrates processor 102 receiving a memory access request from a requester, such as IOA 130 or attached device 142. The memory access request, which may generally be a read-type request requesting return of data or a write-type request requesting update of data, specifies a request address to be accessed. In the case where the requester is not a malicious or compromised device, the request address will be the sRA that would have been previously provided to the requester by processor 102 by the process of FIG. 3. However, if the requester is a malicious or compromised device, the request address may be an illegal address or a real address outside the range of real addresses that the requester is authorized to access.

[0036] In response to receiving the memory access request, the processor 102 decrypts the request address (block 404). For example, if the encryption engine 204 uses a hash function to generate the sRA, the decryption engine 206 may use a corresponding inverse hash function to decrypt the request address in block 404. Alternatively, if the encryption engine 204 uses a key-based encryption function to generate the sRA, the decryption engine 206 may use the same key that was used to encrypt the sRA to decrypt the request address in block 404. Again, the decryption engine 206 may access an associated key in the key store 208 based on the requester's identity (or RID / PASID combination), which is preferably communicated by the requester in or in conjunction with the memory access request, or implied in part or in full by the requester's location on the attached I / O bus. Assuming that the bits of the intermediate RA were shuffled in block 310 of FIG. 3, the processor 102 also unshuffles the bits of the decoded request address to reverse the reordering of bit positions performed in block 310 (block 406).

[0037] At block 408, the processor 102 checks at least a portion of the decoded request address to determine whether the decoded request address is a valid RA. For example, in an embodiment in which the processor 102 adds a host field to pad the RA at block 308 of FIG. 3, the security logic 202 of the processor 102 may determine at block 408 whether the host field of the decoded request address matches the host field added to the RA at block 308. The check performed at block 408 may alternatively or additionally include the RAV logic 212 performing real address validation of some or all of the RA bits of the decoded request address. At block 410, the processor 102 determines whether the checks performed at block 408 were all successful. Based on a determination at block 410 that one or more checks performed at block 408 were all successful, the request address is confirmed to be a proper sRA, and the processor 102 enables access to a resource within the data processing system 100 identified by the decoded RA (e.g., a location within the system memory 116) (block 412). However, if the processor 102 determines at block 410 that one or more of the checks performed at block 410 were not successful, the processor 102 does not permit the requested access to the resource of the data processing system 100 identified by the decoded request address, if applicable (block 414). Additionally, at block 414, the processor 102 stops operation of the requester to terminate the requester's generation of potentially malicious memory access requests. The processor 102 may also optionally reset (restart) the requester to return it to a known stable state from which it may again be permitted to issue memory access requests. Following either block 412 or block 414, the process of FIG. 4 ends at block 416.

[0038] 5A, an exemplary process is shown in which processor 102 encrypts a real address (RA) to obtain a secure real address (sRA), according to one embodiment. In the illustrated example, security logic 202 receives RA 500 from IOMMU 200. In the illustrated example where processor 102 supports 64-bit real addressing, RA 500 may include a smaller number of bits, such as 52 bits. The length of the RA reflects the fact that I / O requesters, such as IOA 130 and attached devices 142, generally do not need to address (or are limited to address) the complete RA space of data processing system 100. RA 500 includes an upper bit field 502 and a lower bit field 504. In the illustrated example, the boundary between upper bit field 502 and lower bit field 504 is selected to correspond to the size of a memory page assigned (e.g., by an operating system or hypervisor software) to the associated requester. In this example, the lower bit field, which is 21 bits long, corresponds to a memory page size of 2 MB. As shown, processor 102 preferably avoids encrypting the contents of the low-order bit field because a requestor accessing or modifying the contents of one of its own allocated memory pages is, by definition, not a security threat. Excluding low-order bit field 504 from encryption simplifies the encryption performed by encryption engine 204 and improves encryption performance.

[0039] As described above with reference to block 308 of FIG. 3, the security logic 202 may pad the truncated RA 500 (which now includes only the most significant bit field 502) with a desired number of bits comprising the host field (HF) 506 to obtain a desired number of bits for encryption. For example, in the illustrated example, the host field 506 may be selected to be 12 bits long such that the intermediate RA has a total length of 43 bits. In other embodiments, a greater or lesser number of bits may be included in the host field 506. In various embodiments, a variety of different information may be encoded within the host field 506. For example, FIG. 6 illustrates an exemplary embodiment in which the host field 506 includes a translation context field 600 in which the processor 102 records a translation context for the VA to sRA translation. For example, in an embodiment in which the processor 102 and the requester communicate utilizing a PCIe ATS protocol, the translation context may include bits from the RID and / or PASID associated with the VA to sRA translation. In one particular example, translation context field 600 includes a concatenation of the associated RID and PASID. FIG. 6 further illustrates that processor 102 may optionally include, within host field 506, a read-only (RO) field 602 that specifies whether RA 500 is mapped to a memory page identified as a read-only memory page, e.g., in page protection information maintained within IOMMU 200. In an embodiment in which host field 506 includes RO field 602, security logic 202 may include, in the check performed at block 408, a check whether the memory access request is a write type request and RO field 602 is set to indicate a read-only memory page. In such a case, security logic 202 fails the check at block 410 of FIG. 4. In some embodiments, host field 506 may alternatively or additionally include a key generation field, as discussed further below with reference to FIGS. 8-9.

[0040] Returning to FIG. 5A, following padding of the upper bit field 502 with the host field 506, an entropy mixer 510 in the encryption engine 204 may optionally reorder at least a portion of the bit positions of the 43-bit intermediate RA to increase entropy. Generally, this reordering of bit positions involves dispersing the less significant bits of the upper bit field 502, which tend to have a greater variation in bit values ​​between RAs, among the 43-bit positions of the intermediate RA. The intermediate RA is then encrypted by encryption logic 512 in the encryption engine 204 to obtain a 43-bit encrypted field 522. The encrypted field 522 is concatenated with the unencrypted 21-bit lower bit field 504 to form an encrypted sRA 520 that the processor 102 may securely return to the requester without exposing the actual corresponding RA to discovery by the requester.

[0041] 5B, an exemplary process of decrypting sRA 520 to obtain a corresponding real address is shown according to one embodiment. In response to receiving sRA 520 returned to security logic 202, for example in a memory access request, decryption logic 514 in decryption engine 206 decrypts encrypted field 522. Entropy demixer 516 in decryption engine 206 reverses the bit shuffling performed by entropy mixer 510 to obtain high-order bit field 532 and decrypted host field 534, which together with low-order bit field 504 form decrypted RA 530. As described above with respect to blocks 408 and 410 of FIG. 4, security logic 202 may check decrypted host field 534 to determine whether decrypted real address 530 is an approved real address for the requester. Additionally, security logic 202 may utilize RAV logic 212 to alternatively or additionally check the RA bits found in high-order bit field 532 and low-order bit field 504.

[0042]

[0033] Referring now to Figure 7, there is shown a high-level data flow diagram of an exemplary process by which the processor 102 may encrypt a real address to obtain an encrypted secure real address (sRA), according to one embodiment. In particular, Figure 7 illustrates a two-stage key-based encryption process, which is only one of countless possible encryption techniques that may be applied by the encryption engine 204; in other embodiments, other encryption techniques may alternatively be employed.

[0043] In the illustrated encryption technique, the 31-bit upper bit field 502 of Figure 5A is divided into eight nibbles, labeled HO1 through HO8, from most significant to least significant (HO2 is a short nibble containing only 3 bits). In this example, nibbles HO1 and HO2 are reserved for the second stage of encryption and are not processed through entropy mixer 510. The bit positions of the remaining 36 bits (the three nibbles of host field 506 and the six nibbles of upper bit field 502) are mixed in a predetermined pattern by entropy mixer 510 to generate a 36-bit first intermediate RA 700, shown as nine 4-bit nibbles.

[0044] The encryption engine 204 encrypts the intermediate RA 700 (and the seven bits of the high-order bit field 502) in two stages. In the first stage, the encryption engine 204 logically combines the first encryption key ("Key1") with additional data to obtain a modified first encryption key. In the illustrated example, this additional data is a requestor-related identifier, such as the RID associated with the address translation request, or a concatenation of the RID and the PASID. In the illustrated example, the encryption engine 204 logically combines the first encryption key and the additional data using an exclusive OR (XOR) operation 705. The encryption engine 204 then encrypts the intermediate RA 700 using the modified first encryption key, for example, using a first stage Advanced Encryption Standard (AES)-based encryption logic 702. In some examples, the AES-based encryption scheme implemented by the first stage AES-based encryption logic 702 can be a mini-AES-based encryption scheme employing a 36-bit key. An example of such a mini-AES based encryption scheme is described below with reference to Figure 10. The output of the first stage AES based encryption logic 702 is a 36-bit first cipher 704, shown as nine 4-bit nibbles.

[0045] The encryption engine 204 reserves the seven most significant bits of the first cipher 704 for later use. The encryption engine 204 forms a second intermediate RA 706 by concatenating the 29 less significant bits of the first cipher 204 with the reserved nibbles HO1 and HO2 from the most significant bits field 502.

[0046] In the second stage of encryption, the encryption engine 204 logically combines (e.g., using an XOR operation 707) the second encryption key ("Key2") with the additional data to obtain a modified second encryption key. As described above, this additional data may be a requestor-related identifier, such as the RID associated with the address translation request, or a concatenation of the RID and the PASID. The encryption engine 204 then encrypts the second intermediate RA 706 using the modified second encryption key (e.g., a 36-bit key), e.g., using the second stage AES-based encryption logic 708. In some examples, the second stage AES-based encryption logic 708 may be identical to and / or reuse the same circuitry as the first stage AES-based encryption logic 702. The output of the second stage AES-based encryption logic 708 is a 36-bit second cipher 710, shown as nine 4-bit nibbles. The encryption engine 204 may then form the 43-bit encrypted field 522 of the sRA 520 by concatenating the 7 most significant bits of the first cipher 704 reserved following the first stage of encryption with the 36-bit second cipher 710. As shown in FIG. 5A, the security logic 202 then appends the unencrypted 21-bit lower bit field 504 to the encrypted field 522 to form the complete 64-bit sRA 520.

[0047] 8, a partial diagram of security logic 202 of FIG. 2 is illustrated showing the portion thereof that supports the use of key generation, according to one embodiment.

[0048] Over time, a hypervisor or operating system instance responsible for allocating memory pages in the real address space of data processing system 100 will reallocate various memory pages to different processes and / or different logical partitions (LPARs). As memory pages are reallocated, processor 102 will generally invalidate the corresponding translation entries in its IOMMU 200 and in its associated requester's ATC 220, for example by sending a translation invalidation request. If a requester receiving a translation invalidation request is non-malicious and bug-free, the requester will comply with processor 102's translation invalidation request and invalidate each indicated translation in its ATC 220. However, if the requester is malicious or compromised, the requester may not invalidate the translations in its ATC 220 in response to the translation invalidation request, but instead may retain the old sRA and subsequently attempt to reuse the old sRA to access a portion of the real address space not currently assigned to the requester.

[0049] In at least some embodiments, security logic 202 is configured to transparently update the usage of encryption keys in key store 208 to prevent malicious or compromised requesters from being able to successfully reuse old sRAs. In the embodiment of FIG. 8, security logic 202 preferably implements a respective generation (G) field 800 associated with an encryption key assigned to each supported requester. Generation field 800 specifies which generation of encryption key is utilized. For example, assuming only two encryption key generations (e.g., denoted as key generations A and B) are supported, key store 208 may contain, for each supported requester, Key1 and Key2 for key generations A and B, respectively. Thus, key store 208 contains, for a given requester, Key1A and Key2A, which are keys for use during key generation A, and Key1B and Key2B, which are keys for use during key generation B.

[0050] With this arrangement, at one point in time, generation field 800 will have a value of b'0', for example, representing key generation A. As a result, security logic 202 will select (e.g., using multiplexer 802) Key1A and Key2A for use by encryption engine 204 in generating encrypted field 522 of sRA 520. At a different point in time, generation field 800 will have a value of b'1', for example, representing key generation B. Based on generation field 800 indicating key generation B, security logic 202 will select (e.g., using multiplexer 802) Key1B and Key2B for use by encryption engine 204 in generating encrypted field 522 of sRA 520. In either case, the value of generation field 800 is placed into generation field 804 that is appended to the encryption output by encryption engine 204 to obtain encrypted field 522 of sRA 520. Note that in the illustrated embodiment, the encryption engine 204 is configured to generate a 42-bit cipher rather than the 43-bit second cipher 710 of Figure 7. In at least one implementation, this result may be achieved by reducing the length of the host field 506 from 12 bits to 11 bits.

[0051] In response to receiving a request address 810 from a requester along with a memory access request, the security logic 202 selects (e.g., using a multiplexer 812) a key to be utilized in decrypting the request address 810 based on the generation field 804 of the request address 810. The security logic further preferably includes a comparator 812 that detects whether the key generation specified by the generation field 804 of the request address 810 remains a valid key generation, and if not, causes the security logic 202 to reject the request address 810 as false.

[0052]

[0046] Referring now to Figure 9, there is shown a high level logic flow diagram of an exemplary process by which processor 102 implements key generation, according to one embodiment. For ease of understanding, the process presented in Figure 9 is described with reference to the implementation of security logic 202 illustrated in Figure 8, which employs two alternating key generations, referred to as key generations A and B.

[0053] As shown, the process of FIG. 9 begins at block 900 and then proceeds to block 901 which illustrates the security logic 202 of the processor 102 initializing a current key generation as key generation A. The process then proceeds to block 902 which illustrates the security logic 202 generating two different keys (e.g., Key1A and Key2A) during the current key generation (e.g., key generation A) for use in generating an sRA 520 for the requester. For example, the security logic 202 may generate the keys using key generation logic 210 such as a Linear-Feedback Shift Register (LFSR) or AES key generation logic. Additionally, at block 902, the security logic 202 sets a value of b'0' in the generation field 800 to indicate that key generation A is the current key generation applicable to the requester. While key generation A remains the current key generation, encryption engine 204 and decryption engine 206 of security logic 202 utilize the keys associated with generation A, i.e., Key1A and Key2A, to generate an sRA 520 to be transmitted to the requester, decrypt the request address received from the requester, and reject the request address generated with the key for key generation B (block 904).

[0054] At decision block 906, the processor 102 determines whether to use a new key generation for the requester. For example, in some embodiments or use cases, the processor 102 may determine to utilize a new key generation based at least in part on a remapping of some or all of the address space previously assigned to the requester (or the LPAR to which the requester is assigned). In some embodiments or use cases, the processor 102 may determine to initiate a new key generation for the requester based at least in part on a software command. In some embodiments or use cases, the processor 102 may determine a frequency of change of the key generation based at least in part on attributes of the encryption algorithm employed by the encryption engine 204. If the processor 102 does not make an affirmative determination at block 906, the process returns to block 904 as described. However, if the processor 102 makes a positive determination at block 906, the process proceeds to block 908, which illustrates the security logic 202 of the processor 102 generating two different keys (e.g., Key1B and Key2B) for use in generating sRAs 520 for the requester during a new current key generation (e.g., key generation B). As described above, the security logic 202 may generate the keys using the key generation logic 210. Additionally, at block 908, the security logic 202 sets the generation field 800 to a value associated with the current key generation applicable to the requester (e.g., a value of b'1' for key generation B). The security logic 202 additionally sends a conversion invalidation request to the requester for all sRAs in the previous key generation (e.g., key generation A), e.g., as specified by the value identified in the generation field 804 (block 910). In response to a conversion invalidation request, a non-malicious or uncompromised requester will invalidate any VA-to-sRA conversions in its ATC 220 that reference sRAs generated during a previous key generation (e.g., key generation A).

[0055] As illustrated by blocks 912-916, following issuance of the conversion invalidation request, and until an acknowledgement of the requested invalidation is received from the requester (block 914) or a timeout period has elapsed (block 916), security logic 202 exclusively utilizes the key for the current key generation (e.g., key generation B) to generate the sRA, but utilizes the key for generation A or generation B to decrypt the requested address. By continuing to support the requested address in the previous key generation (e.g., key generation A) until the invalidation is acknowledged or the timeout period has elapsed, security logic 202 ensures a seamless and transparent transition between key generations from the requester's perspective. In response to receipt by security logic 202 of an invalidation acknowledgement or the timeout period having elapsed, the process returns to block 904. As a result, the encryption engine 204 and decryption engine 206 of the security logic 202 utilize only the keys associated with the current key generation (e.g., Key1B and Key2B of key generation B) to generate the sRA 520 transmitted to the requester and to decrypt the request address received from the requester. Additionally, the security logic 202 rejects any incoming request address that identifies a non-current key generation in the generation field 804 based on the comparator 812 detecting a mismatch between the contents of the generation fields 800 and 804. In this manner, the security logic 202 prevents the reuse of any old sRA that should have been invalidated by the requester in response to the conversion invalidation request issued in block 910. Following block 904, the process presented in FIG. 9 continues to block 906 and subsequent blocks as described. In at least some embodiments, in response to determining at block 916 that a timeout period has elapsed without receiving an acknowledgment by the requester of the invalidation of the sRA for the previous key generation, the processor 102 may additionally reset the requester.

[0056] 10, there is shown a data flow diagram of an exemplary AES-based encryption process that may be utilized in generating sRA 520, according to one embodiment. Specifically, the illustrated example shows a modified mini-AES encryption process that may be performed by first stage AES-based encryption logic 702 or second stage AES-based encryption logic 708. In the illustrated embodiment of FIG. 10, Key(n) is the output of either XOR 705 or 707 of FIG.

[0057] In the first round of the modified mini-AES encryption process, the encryption engine 204 first logically combines the 36-bit intermediate RA 700 or 706 with the 36-bit modified Key(n), for example by performing an XOR operation 1002. The resulting 36-bit working value is then placed into a matrix, for example a 3×3 matrix with each matrix entry holding one of nine nibbles. The contents of the matrix may then be subject to conventional matrix manipulations, including via a permutation step 1004, a row shift step 1006, and a column shuffling step 1008.

[0058] In a second round of the modified mini-AES encryption process 1000, the encryption engine 204 again logically combines the 36-bit working value with the 36-bit modified Key(n), for example by performing an XOR operation 1010. The resulting 36-bit working value is then subject to another round of matrix manipulation, including a permutation step 1012, a row shift step 1014, and an optional column mixing step 1016. Note that the column mixing step 1016 is not performed in conventional mini-AES encryption processes, and serves to further protect the sRA. The 36-bit value resulting from the illustrated processing may then be utilized as a cipher 704 or 710, as previously described in FIG.

[0059] As has been described, in at least one embodiment, a data processing system provides enhanced I / O security while supporting address translation services for attached devices.

[0060] In at least one embodiment, a processor receives a first request from a requester, the requester including a virtual address. Based on the first request, the processor determines a real address corresponding to the virtual address, encrypts at least a portion of the real address to obtain an encrypted secure real address, and returns the encrypted secure real address to the requester. Based on receiving a second request identifying the request address, the processor decrypts the request address and verifies the request address as an encrypted secure real address. Based on verifying the request address as an encrypted secure real address, the processor enables access to a resource of the data processing system identified by the real address. The use of encrypted secure real addresses provides improved security and generally requires a smaller footprint to implement compared to table-based real address verification approaches.

[0061] In some embodiments, a requester may be an input / output (I / O) adapter. For example, in one particular embodiment, the adapter may communicate the request to the processor using the Peripheral Component Interconnect Express Address Translation Service (PCIe ATS) protocol. In other embodiments, a requester may be an attached device, such as an accelerator, that employs a virtual address space.

[0062] In some embodiments, at least a portion of the real address is encrypted using Advanced Encryption Standard (AES) based encryption. In some embodiments, encrypting at least a portion of the real address alternatively or additionally includes generating a hash of at least a portion of the real address. Using a strong encryption technique such as AES has the advantage of increased security, and using a hash has the advantage of high performance.

[0063] In some embodiments, the processor avoids encrypting the less significant bits of the real address that are used to identify an address within a memory page. By not encrypting the full real address (e.g., 64 bits), encryption is simplified and performance is improved.

[0064] In some embodiments, the encryption may be further strengthened by combining additional data with at least a portion of the real address prior to encryption. In some embodiments, the additional data may include bits from the requestor's process address space identifier and / or bits from a requestor identifier. In some embodiments, the additional data may alternatively or additionally include a read-only field indicating whether access to the real address by the requestor is read-only. In some embodiments, the additional data may include a key generation field that identifies which key from multiple keys was utilized to encrypt the real address.

[0065] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer readable storage medium (or multiple computer readable storage media) having computer readable program instructions for causing a processor to perform aspects of the present invention.

[0066] A computer readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage media includes the following: portable computer diskettes, hard disks, Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM or Flash memory), Static Random Access Memory (SRAM), portable Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves on which instructions are recorded, and any suitable combination of the above. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0067] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to the respective computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0068] The computer readable program instructions for carrying out the operations of the present invention may be either assembler instructions, Instruction-Set-Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk or C++, and traditional 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, as a standalone 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 scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to carry out aspects of the invention.

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

[0070] These computer readable program instructions may be provided to processors of general purpose and special purpose computers, or other programmable data processing apparatus to produce a machine such that the instructions, executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored in a computer readable storage medium that may direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams.

[0071] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus or other device to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus or other device implement the functions / operations identified in one or more blocks of the flowcharts and / or block diagrams.

[0072] 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 invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in reverse order depending on the functionality involved. It should 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, may be implemented by a dedicated hardware-based system that executes the specified functions or operations, or executes a combination of dedicated hardware and computer instructions.

[0073] While the present invention has been specifically illustrated as described with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the appended claims. For example, while examples of addresses and address fields of particular lengths have been discussed, those skilled in the art will understand that the invention described herein is not limited to the exemplary address and address field lengths. In addition, it is important to note that the described invention may be employed in both virtualized and non-virtualized environments. For example, in various embodiments or use cases, a requester may be assigned to a VM, a hypervisor, or a bare metal OS. Furthermore, while aspects have been described with respect to data processing hardware directing particular functions, it will be understood that the present invention may alternatively be implemented as a program product including a storage device that stores program code that performs such functions or that can be processed by a processor to cause such functions to be performed. As employed herein, "storage device" is specifically defined to include only statutory articles of manufacture and to exclude signal media per se, ephemeral propagating signals per se, and energy per se.

[0074] The figures and written description set forth above of the specific structure and function are not presented to limit the scope of the applicant's invented matter or the scope of the appended claims. Rather, the figures and written description are provided to teach any person of ordinary skill in the art to make and use the invention for which patent protection is sought. Those skilled in the art will appreciate that, for clarity and understanding, not all features of the commercial embodiment of the invention have been described or shown. Those skilled in the art will also appreciate that the development of an actual commercial embodiment incorporating aspects of the present invention will require numerous implementation-specific decisions to achieve the developer's end goal for that commercial embodiment. Such implementation-specific decisions may include, but are perhaps not limited to, compliance with system-related, business-related, government-related, and other constraints that may vary from one particular implementation to another, from one location to another, and from one time to another. While the developer's efforts may be complex and time-consuming in an absolute sense, such efforts will nevertheless be routine for those skilled in the art having the benefit of this disclosure. It should be understood that the invention disclosed and taught herein is susceptible to numerous and various modifications and alternative forms. Finally, the use of singular terms such as, but not limited to, "a" is not intended to limit the number of items.

Claims

1. A method of data processing in a data processing system equipped with a processor, the method being used for data processing: The processor receives a first request from the requester, which includes a virtual address; In the first step, based on the first request, the processor determines the real address corresponding to the virtual address, encrypts at least a portion of the real address to obtain an encrypted secure real address, and returns the encrypted secure real address to the requester, The aforementioned encryption is The processor holds a value in a key generation field that identifies the current key generation from among a plurality of different key generations, and the holding includes repeatedly and cyclically holding the value of the key generation field among the plurality of different key generations; Based on the current key generation identified by the key generation field, the processor selects one key from among several different keys for use in the encryption; Based on the remapping of the virtual address space including the virtual address, the processor advances the value of the key generation field to identify a new key generation following the current key generation. Stages including; A step in which, based on receiving a second request that identifies the requested address, the processor decrypts the requested address and verifies the requested address as the encrypted secure real address; and Based on the step of verifying the requested address as the encrypted secure real address, the processor enables access to the resource of the data processing system identified by the real address. A data processing method having [a certain characteristic].

2. A data processing method in a data processing system comprising a processor: The processor receives a first request from the requester, which includes a virtual address; A step in which, based on the first request, the processor determines the physical address corresponding to the virtual address, encrypts at least a portion of the physical address to obtain an encrypted secure physical address, and returns the encrypted secure physical address to the requester, wherein the step of encrypting at least a portion of the physical address includes a step of avoiding encrypting the lower bits of the physical address that are used to identify the address in the memory page; A step in which, based on receiving a second request that identifies the requested address, the processor decrypts the requested address and verifies the requested address as the encrypted secure real address; and Based on the step of verifying the requested address as the encrypted secure real address, the processor enables access to the resource of the data processing system identified by the real address. A data processing method having [a certain characteristic].

3. A data processing method in a data processing system comprising a processor: The processor receives a first request from the requester, which includes a virtual address; Based on the first request, the processor determines the real address corresponding to the virtual address, combines the additional data with at least a portion of the real address, encrypts at least a portion of the real address to obtain an encrypted secure real address, and returns the encrypted secure real address to the requester; A step in which, based on receiving a second request that identifies the requested address, the processor decrypts the requested address and verifies the requested address as the encrypted secure real address; and Based on the step of verifying the requested address as the encrypted secure real address, the processor enables access to the resource of the data processing system identified by the real address. It has, A data processing method wherein the additional data includes a key generation field that identifies which key was used from among multiple keys to encrypt the actual address.

4. The data processing method according to any one of claims 1 to 3, wherein the step of receiving the first request includes the step of receiving a Peripheral Component Interconnection Express Address Translation Service (PCIe ATS) protocol request.

5. The data processing method according to any one of claims 1 to 3, wherein the step of encrypting at least a portion of the actual address includes the step of encrypting at least a portion of the actual address using Advanced Encryption Standard (AES) based encryption.

6. The data processing method according to any one of claims 1 to 3, wherein the step of encrypting at least a portion of the actual address includes the step of generating a hash of at least a portion of the actual address.

7. The data processing method according to claim 1 or 2, further comprising the step of combining additional data with at least a portion of the actual address prior to the encryption step.

8. The data processing method according to claim 7, wherein the additional data includes at least one of the following sets: bits from the process address space identifier of the requester and bits from the requester identifier.

9. The data processing method according to claim 7, wherein the additional data includes a read-only field indicating whether the access to the actual address by the requester is read-only.

10. A data processing system, Procedure for receiving a first request from the requester, including a virtual address; A procedure comprising: determining the actual address corresponding to the virtual address based on the first request, encrypting at least a portion of the actual address to obtain an encrypted secure actual address, and returning the encrypted secure actual address to the requester, The aforementioned encryption is Maintaining a value in a key generation field that identifies the current key generation from among several different key generations, wherein the retention includes repeatedly and cyclically maintaining the value of the key generation field among the several different key generations; Based on the current key generation identified by the key generation field, one key is selected from a group of different keys for use in the encryption; Based on the remapping of the virtual address space including the aforementioned virtual address, the value of the key generation field is advanced to identify a new key generation following the current key generation; Procedures including; A procedure for decrypting the requested address and verifying the requested address as the encrypted secure real address, based on receiving a second request that identifies the requested address; and A procedure that enables access to the resources of the data processing system identified by the real address, based on a procedure for verifying the requested address as the encrypted secure real address. A processor configured to perform A data processing system equipped with the following features.

11. A data processing system, Procedure for receiving a first request from the requester, including a virtual address; A procedure for determining the physical address corresponding to the virtual address based on the first request, obtaining an encrypted secure physical address by encrypting at least a portion of the physical address, and returning the encrypted secure physical address to the requester, wherein the procedure for encrypting at least a portion of the physical address includes a step of avoiding encrypting the lower bits of the physical address that are used to identify the address in the memory page; A procedure for decrypting the requested address and verifying the requested address as the encrypted secure real address, based on receiving a second request that identifies the requested address; and A procedure that enables access to the resources of the data processing system identified by the real address, based on a procedure for verifying the requested address as the encrypted secure real address. A processor configured to perform A data processing system equipped with the following features.

12. A data processing system, Procedure for receiving a first request from the requester, including a virtual address; A procedure to determine the actual address corresponding to the virtual address based on the first request, combine additional data with at least a portion of the actual address, encrypt at least a portion of the actual address to obtain an encrypted secure actual address, and return the encrypted secure actual address to the requester; A procedure for decrypting the requested address and verifying the requested address as the encrypted secure real address, based on receiving a second request that identifies the requested address; and A procedure that enables access to the resources of the data processing system identified by the real address, based on a procedure for verifying the requested address as the encrypted secure real address. A processor configured to perform Equipped with, The data processing system includes a key generation field that identifies which of several keys was used to encrypt the actual address.

13. The data processing system according to any one of claims 10 to 12, wherein the procedure for receiving the first request includes a procedure for receiving a Peripheral Component Interconnection Express Address Translation Service (PCIe ATS) protocol request.

14. The data processing system according to any one of claims 10 to 12, wherein the procedure for encrypting at least a portion of the actual address includes a procedure for encrypting at least a portion of the actual address using Advanced Encryption Standard (AES) based encryption.

15. The data processing system according to any one of claims 10 to 12, wherein the procedure for encrypting at least a portion of the actual address includes a procedure for generating a hash of at least a portion of the actual address.

16. The aforementioned processor is: A procedure to combine additional data with at least a portion of the actual address, prior to the encryption procedure. The data processing system according to claim 10 or 11, further configured to perform the following:

17. The data processing system according to claim 16, wherein the additional data includes at least one of the following sets: bits from the process address space identifier of the requester and bits from the requester identifier.

18. The data processing system according to claim 16, wherein the additional data includes a read-only field indicating whether the access to the actual address by the requester is read-only.

19. System memory coupled to the aforementioned processor; and The requester coupled to the processor via the bus A data processing system according to any one of claims 10 to 12, further comprising:

20. Storage devices; and Program code stored in the aforementioned storage device The program code, when executed by the processor, is sent to the processor: Procedure for receiving a first request from the requester, including a virtual address; A procedure comprising: determining the actual address corresponding to the virtual address based on the first request, encrypting at least a portion of the actual address to obtain an encrypted secure actual address, and returning the encrypted secure actual address to the requester, The aforementioned encryption is Maintaining a value in a key generation field that identifies the current key generation from among several different key generations, wherein the retention includes repeatedly and cyclically maintaining the value of the key generation field among the several different key generations; Based on the current key generation identified by the key generation field, the processor selects one key from among several different keys for use in the encryption; Based on the remapping of the virtual address space including the virtual address, the processor advances the value of the key generation field to identify a new key generation following the current key generation; Procedures including; A procedure for decrypting the requested address and verifying the requested address as the encrypted secure real address, based on receiving a second request that identifies the requested address; and A procedure that enables access to the data processing system resource identified by the real address, based on a procedure for verifying the requested address as the encrypted secure real address. A computer program that executes something.

21. Storage device; and Program code stored in the aforementioned storage device The program code, when executed by the processor, is sent to the processor: Procedure for receiving a first request from the requester, including a virtual address; A procedure for determining the physical address corresponding to the virtual address based on the first request, obtaining an encrypted secure physical address by encrypting at least a portion of the physical address, and returning the encrypted secure physical address to the requester, wherein the procedure for encrypting at least a portion of the physical address includes a step of avoiding encrypting the lower bits of the physical address that are used to identify the address in the memory page; A procedure for decrypting the requested address and verifying the requested address as the encrypted secure real address, based on receiving a second request that identifies the requested address; and A procedure that enables access to the data processing system resource identified by the real address, based on a procedure for verifying the requested address as the encrypted secure real address. A computer program that executes something.

22. Storage devices; and Program code stored in the aforementioned storage device The program code, when executed by the processor, is sent to the processor: Procedure for receiving a first request from the requester, including a virtual address; A procedure to determine the real address corresponding to the virtual address based on the first request, combine the additional data with at least a portion of the real address, encrypt at least a portion of the real address to obtain an encrypted secure real address, and return the encrypted secure real address to the requester; A procedure for decrypting the requested address and verifying the requested address as the encrypted secure real address, based on receiving a second request that identifies the requested address; and A procedure that enables access to the data processing system resource identified by the real address, based on a procedure for verifying the requested address as the encrypted secure real address. Make it run, The additional data includes a key generation field that identifies which of several keys was used to encrypt the actual address. Computer program.

23. The computer program according to any one of claims 20 to 22, wherein the procedure for receiving the first request includes a procedure for receiving a Peripheral Component Interconnection Express Address Translation Service (PCIe ATS) protocol request.

24. The computer program according to any one of claims 20 to 22, wherein the procedure for encrypting at least a portion of the actual address includes a procedure for encrypting at least a portion of the actual address using Advanced Encryption Standard (AES) based encryption.

25. The computer program according to any one of claims 20 to 22, wherein the procedure for encrypting at least a portion of the actual address includes a procedure for generating a hash of the at least portion of the actual address.

Images