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 specifically to input / output (I / O) security in a data processing system.

[0002] A data processing system may include a plurality of processing elements and a plurality of 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 are logically partitioned into a plurality of sets of resources, each controlled by a respective one of a plurality of, possibly different, operating system instances. The operating systems execute concurrently on this common hardware platform within their respective Logical Partitions (LPARs) under the control of system firmware commonly referred to as a Virtual Machine Monitor (VMM) or a hypervisor. Accordingly, the hypervisor allocates a non-overlapping 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 areas of system memory and IOAs.

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

[0004] More recently, at least several I / O standards, such as Peripheral Component Interconnect Express (PCIe), have introduced an Alternative Address Translation Service (ATS) that allows an IOA to request a translation of an I / O address and, in response, receive the corresponding real address from the host bridge. 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 identify the real address. By allowing IOAs to make memory access requests using real addresses while improving latency for accesses that refer to frequently accessed or recently accessed addresses, host system memory can be exposed to access by malicious or compromised I / O devices, thus raising significant security concerns. At least some prior art systems partially mitigate this security concern by performing real address verification on incoming I / O memory access requests, ensuring that each IOA accesses only authorized real address pages. However, this address translation service implementation has proven to be underperforming and costly to implement due to the memory footprint required to store the tables traditionally used for performing real address verification. These drawbacks worsen in implementations where real address verification employs fine-grained verification based on both the Requestor Identifier (RID) and the Process Address Space Identifier (PASID). [Overview of the Initiative]

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

[0006] In various embodiments, the disclosed techniques may be implemented in methods, data processing systems, and / or program products.

[0007] In at least one embodiment, the processor receives a first request from a requester, which includes a virtual address. 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. Based on receiving a second request that identifies the requested address, the processor decrypts the requested address and verifies it as an encrypted secure real address. Based on verifying the requested address as an encrypted secure real address, the processor enables access to the data processing system resource identified by the real address. The use of encrypted secure real addresses provides enhanced security and generally requires a smaller footprint for implementation compared to table-based real address verification methods.

[0008] In some embodiments, the requester may be an input / output (I / O) adapter. For example, in a 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, the requester may be an auxiliary device such as an accelerator that employs a virtual address space.

[0009] In some embodiments, at least a portion of the real addresses are encrypted using Advanced Encryption Standard (AES) based encryption. In some embodiments, encrypting at least a portion of the real addresses may, alternatively or additionally, involve generating hashes of at least a portion of the real addresses. Using strong encryption techniques such as AES offers the advantage of enhanced security, while using hashes offers the advantage of high performance.

[0010] In some embodiments, the processor avoids encrypting the lower bits of the actual address used to identify the address in the memory page. By not encrypting the complete actual address (e.g., 64 bits), encryption is simplified and performance is improved.

[0011] In some embodiments, encryption can be further enhanced 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 requester's process address space identifier and / or bits from the requester identifier. In some embodiments, the additional data may, alternatively or additionally, include a read-only field indicating whether the requester's access to the real address is read-only. In some embodiments, the additional data may include a key that identifies which of several keys was used to encrypt the real address. generation May include fields. [Brief explanation of the drawing]

[0012] [Figure 1] A high-level block diagram of an exemplary data processing system according to one embodiment is shown.

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

[0014] [Figure 3] This is a high-level logical flowchart of an exemplary process in which a processor provides an encrypted secure real address (sRA) to a requester, according to one embodiment.

[0015] [Figure 4] This is a high-level logic flowchart of an exemplary process in which a processor handles a requester's memory access request, according to one embodiment.

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

[0017] [Figure 6] An example of the contents of the host field of a real address according to one embodiment is shown.

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

[0019] [Figure 8] This is a partial diagram showing a portion of the security logic of a processor that supports the use of key generations, according to one embodiment.

[0020] [Figure 9] This is a high-level logic flowchart of an exemplary process in which a processor implements key generations, according to one embodiment.

[0021] [Figure 10] is a data flow diagram of an exemplary AES-based encryption process that can be used to generate an encrypted secure physical address according to one embodiment. Mode for Carrying Out the Invention

[0022] Referring now to the figures, and particularly to FIG. 1, there is illustrated 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, for example, a Symmetric MultiProcessor (SMP) system including a plurality of processors 102a-102n, each coupled for communication to a system fabric 104, which may include one or more buses or switched communication links. In alternative embodiments, a data processing system having a single processor 102 may be utilized.

[0023] In the illustrated embodiments, each processor 102 is preferably implemented as a single integrated circuit chip having a semiconductor substrate on which an integrated circuit is fabricated, as is known in the art. As shown, each processor 102 includes a plurality of 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, if applicable, associated data. This program code may include, for example, a hypervisor, one or more operating system instances on which the hypervisor can allocate 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 the data storage hierarchy. In addition, the processor 102 includes an Integrated Memory Controller (IMC) 114 that controls access to one of the associated off-chip system memories 116a to 116n. The processor 102 accesses the system memory 116 using real addresses (RAs) in the real address space. In various embodiments, the actual address may have different lengths, 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, and one or more (and preferably more) host bridges (HB) 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 processing, the IOAs 130 refer to I / O addresses (also referred to as VAs) in the virtual address (VA) space. In various embodiments, 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 from (i.e., shorter or longer than) the length of the RA employed by the processor 102.

[0025] In various embodiments, the host bridge 120 may be communicatively coupled to the IOA 130 directly or indirectly. For example, in the shown embodiment, the host buffers 120a, 120k, 120m, and 120v interface to local buses 122a, 122k, 122m, and 122v, to which the IOA 130 may be directly or indirectly coupled. Thus, the IOA 130a may optionally be coupled to the local bus 122a through an I / O fabric 124a which may comprise one or more switches and / or bridges. Similarly, IOA130k and 130l are optionally coupled to local bus 122k via I / O fabric 124k, IOA130m is optionally coupled to local bus 122m via I / O fabric 124m, and IOA130v and 130w are optionally coupled to local bus 122v via I / O fabric 124v. In some embodiments, communication on one or more local buses 122 utilizes known I / O bus standards such as Peripheral Component Interconnection (PCI) or PCI Express (PCIe) standards. In some embodiments, one or more local buses 122 may employ additional or alternative I / O bus standards.

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

[0027] Those skilled in the art will understand that the architecture and components of the data processing system may differ between embodiments. For example, other devices and interconnections may be used as alternatives or additional components. Accordingly, the exemplary data processing system 100 presented in Figure 1 is not intended to imply any architectural limitations relating to the claimed invention.

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

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

[0030] Although not specifically shown in Figure 2, it should be understood that the ADI140 in Figure 1 can be constructed similarly to the host bridge 120. For example, the ADI140 may include the IOMMU200 and security logic 202. Similar to the IOA130, the accompanying device 142 may also include the ATC220 for caching the VA to sRA conversions obtained from the ADI140.

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

[0032] The process in Figure 3 begins in block 300 and then proceeds to block 302, which shows that processor 102 receives a translation request from an associated requester that identifies the 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, processor 102 uses, for example, the IOMMU 200 to translate the VA into an RA in the real address space of the data processing system 100. From block 304, the process proceeds to an optional block 305, which shows processor 102 preparing the RA for encryption. In the shown embodiments, the preparation of the RA for encryption in block 305 includes several steps (block 306) that include excluding from encryption a number of lower bits of the RA that would be used to identify a specific address in a given memory page. For example, assuming the RA is 64 bits long and processor 102 allocates a 2 MB memory page to the requester, 21 lower bits of the RA are excluded from encryption in block 306. As can be understood, if processor 102 avoids encrypting all bits of the RA, the encryption process is simplified and encryption performance is improved. In block 305, the truncated RA is optionally padded using a host field containing one or more additional bits (block 308). Different embodiments of the host field are described below with reference to Figures 5A and 6. In addition, in block 305, processor 102 may shuffle the bits of the RA to increase the overall entropy (or randomness) of the bit values ​​(block 310). In a preferred embodiment, in block 310, the bit positions are rearranged within the intermediate RA in a fixed, predetermined manner.

[0033] The process in Figure 3 proceeds from block 305 to block 312, indicating that processor 102 encrypts the RA (either the one received from IOMMU 200, or an intermediate RA obtained following block 305, if block 305 is implemented) to obtain an encrypted secure RA (sRA). In some embodiments, the encryption illustrated in block 312 may include a cryptographic engine 204 that hashs the RA. Preferred hash functions may include, for example, SHA-1, SHA-256, or MD-5. In other embodiments, the encryption may optionally or additionally include cryptographic engine 204 encrypting the RA using one or more keys. If key-based encryption is performed, it is preferable that cryptographic engine 204 uses 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 Figures 7 and 10. The processor then provides the requester with the sRA generated by the encryption performed in block 312 (block 314). In at least some embodiments, the processor 102 may communicate the sRA to the requester in the PCIe ATS translation response. In response to receiving the sRA, the requester may cache the VA-to-sRA translation (for example, in ATC220) to facilitate future use of the sRA in memory access requests. Following block 314, the processing of the translation request by the processor 102 ends in block 316.

[0034] Referring now to Figure 4, a high-level logic flowchart is shown illustrating an exemplary process in which the processor 102 handles a requester's memory access request, according to one embodiment. In some implementations, the process in Figure 4 may be performed by the host bridge 120, which receives the memory access request from the IOA 130. The same process may, alternatively or additionally, be performed by the ADI 140 in response to the receipt of a memory access request from the accessory device 142.

[0035] The process begins at block 400 and then proceeds to block 402, which indicates that processor 102 receives a memory access request from a requester, such as IOA 130 or an attached device 142. A memory access request, which can generally be a read-type request asking for the return of data or a write-type request asking for an update of data, identifies the requested address to be accessed. If the requester is not a malicious or compromised device, the requested address will be the sRA that would have been previously provided to the requester by processor 102 through the process in Figure 3. However, if the requester is a malicious or compromised device, the requested address may be an invalid address or a real address outside the range of real addresses that the requester is authorized to access.

[0036] In response to receiving a memory access request, processor 102 decrypts the requested address (block 404). For example, if the cryptographic engine 204 generates an sRA using a hash function, the decryption engine 206 may decrypt the requested address in block 404 using the corresponding inverse hash function. Alternatively, if the cryptographic engine 204 generates an sRA using a key-based cryptographic function, the decryption engine 206 may decrypt the requested address in block 404 using the same key used to encrypt the sRA. Again, the decryption engine 206 may access the relevant key in keystore 208 based on the requester's identification information (or RID / PASID combination), which is preferably communicated by the requester in the memory access request or in conjunction therewith, or is partially or completely indicated by the requester's location on the connected I / O bus. Assuming that the bits of the intermediate RA were shuffled in block 310 in Figure 3, processor 102 also unshuffles the bits of the decoded request address, reversing the bit reordering that occurred in block 310 (block 406).

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

[0038] Referring here to Figure 5A, an exemplary process is shown in one embodiment in which processor 102 encrypts a real address (RA) to obtain a secure real address (sRA). In the illustrated example, security logic 202 receives RA500 from IOMMU 200. In the illustrated example in which processor 102 supports 64-bit real addressing, RA500 may contain fewer bits, such as 52 bits. The length of the RA reflects the fact that I / O requesters, such as IOA 130 and accompanying device 142, generally do not need to address (or are restricted from addressing) the entire RA space of data processing system 100. RA500 includes an upper bit field 502 and a lower bit field 504. In the illustrated example, the boundary between the upper bit field 502 and the lower bit field 504 is chosen to correspond to the size of the memory page allocated to the associated requester (e.g., by the operating system or hypervisor software). In this example, a 21-bit lower bit field corresponds to a 2MB memory page size. As shown, processor 102 preferably avoids encrypting the contents of the lower bit field because, by definition, it is not a security threat for the requester to access or modify the contents of one of its own allocated memory pages. By excluding the lower bit field 504 from encryption, the encryption performed by the encryption engine 204 is simplified and encryption performance is improved.

[0039] As described above with reference to block 308 in Figure 3, the security logic 202 may obtain a desired number of bits for encryption by padding the RA 500 (in this case only including the upper bit field 502) with a desired number of bits, which has a host field (HF) 506. For example, in the example shown, the host field 506 may be selected to be 12 bits long so that the intermediate RA has a total length of 43 bits. In other embodiments, more or fewer bits may be included in the host field 506. In various embodiments, various different information may be encoded within the host field 506. For example, Figure 6 illustrates an exemplary embodiment in which the host field 506 includes a conversion context field 600 in which the processor 102 records the conversion context for the conversion from VA to sRA. For example, in an embodiment in which the processor 102 and the requester communicate using the PCIe ATS protocol, the conversion context may include bits from the RID and / or PASID associated with the conversion from VA to sRA. In a specific example, the translation context field 600 includes the concatenation of the relevant RID and PASID. Figure 6 further shows that the processor 102 may optionally include a Read-Only (RO) field 602 within the host field 506, which specifies whether RA 500 maps to a memory page identified as a read-only memory page in page protection information maintained, for example, within the IOMMU 200. In embodiments where the host field 506 includes the RO field 602, the security logic 202 may include a check in block 408 to determine whether the memory access request is a write-type request and whether the RO field 602 is set to indicate a read-only memory page. In such cases, the security logic 202 fails the check in block 410 of Figure 4. In some embodiments, the host field 506 is a key, as will be further discussed below with reference to Figures 8-9. generation The field may include alternative or additional fields.

[0040] Returning to Figure 5A, following the padding of the upper bit field 502 by the host field 506, the entropy mixer 510 in the cryptographic engine 204 may selectively rearrange at least some of the bit positions of the 43-bit intermediate RA to increase the entropy. Generally, this rearrangement of bit positions involves distributing the lower bits of the upper bit field 502, which tend to have greater variation in bit values ​​between RAs, among the 43-bit positions of the intermediate RA. The intermediate RA is then encrypted by the cryptographic logic 512 in the cryptographic 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, which the processor 102 can securely return to the requester without exposing the actual corresponding RA to discovery by the requester.

[0041] Referring here to Figure 5B, an exemplary process for decrypting sRA520 to obtain the corresponding real address is shown according to one embodiment. For example, in response to the receipt of sRA520 returned to the security logic 202 in a memory access request, the decryption logic 514 in the decryption engine 206 decrypts the encrypted field 522. The entropy demixer 516 in the decryption engine 206 reverses the bit shuffling performed by the entropy mixer 510 to obtain the upper bit field 532 and the decryption host field 534, which together with the lower bit field 504 form the decrypted RA530. As described above with respect to blocks 408 and 410 in Figure 4, the security logic 202 may check the decryption host field 534 to determine whether the decrypted real address 530 is a real address authorized by the requester. Furthermore, the security logic 202 may use the RAV logic 212 to alternatively or additionally check the RA bits found in the upper bit field 532 and the lower bit field 504.

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

[0043] In the illustrated encryption technique, the 31-bit upper bit field 502 in Figure 5A is divided into eight nibbles labeled HO1 to 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 by the entropy mixer 510. The bit positions of the remaining 36 bits (three nibbles in the host field 506 and six nibbles in the upper bit field 502) are mixed in a predetermined pattern by the entropy mixer 510 to generate a 36-bit first intermediate RA700, which is represented as nine 4-bit nibbles.

[0044] The encryption engine 204 encrypts the intermediate RA700 (and the 7 bits of the upper 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 requester-related identifier such as the RID associated with the address translation request, or the concatenation of the RID and PASID. In the shown example, the encryption engine 204 uses an exclusive OR (XOR) operation 705 to logically combine the first encryption key and the additional data. The encryption engine 204 then uses the modified first encryption key to encrypt the intermediate RA700, for example, using the 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 may 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, which is 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 the second intermediate RA706 by concatenating the 29 lower bits of the first cipher 204 with the nibbles HO1 and HO2 reserved from the upper bit field 502.

[0046] In the second stage of encryption, the encryption engine 204 logically combines the second encryption key ("Key2") with additional data (for example, using an XOR operation 707) to obtain a modified second encryption key. As described above, this additional data may be a requester-related identifier such as the RID associated with the address translation request, or the concatenation of the RID and PASID. The encryption engine 204 then uses the modified second encryption key (for example, a 36-bit key) to encrypt the second intermediate RA 706, for example, using the second-stage AES-based encryption logic 708. In some examples, the second-stage AES-based encryption logic 708 may be identical to the first-stage AES-based encryption logic 702, and / or the same circuit may be reused. The output of the second-stage AES-based encryption logic 708 is a 36-bit second cipher 710, which is shown as nine 4-bit nibbles. The encryption engine 204 can then form the 43-bit encrypted field 522 of the sRA520 by concatenating the seven most significant bits of the first cipher 704, which are reserved following the first stage of encryption, with the 36-bit second cipher 710. As shown in Figure 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 sRA520.

[0047] Referring to Figure 8, a partial diagram of the security logic 202 in Figure 2, according to one embodiment, is a key generation The part that supports its use is shown in the diagram.

[0048] Over time, the hypervisor or operating system instance responsible for allocating memory pages in the real address space of the data processing system 100 will reallocate various memory pages to different processes and / or different logical partitions (LPARs). When memory pages are reallocated, processor 102 will generally invalidate the corresponding translation entries in its IOMMU 200 and in the ATC 220 of its associated requester, for example, by sending a translation invalidation request. If the requester that receives the translation invalidation request is not malicious and is bug-free, the requester will invalidate each indicated translation in its ATC 220 in accordance with the translation invalidation request from processor 102. However, if the requester is malicious or its malicious intent is 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 then attempt to reuse the old sRA to access a portion of the real address space that is not currently allocated to the requester.

[0049] In at least some embodiments, the security logic 202 is configured to transparently update the usage of cryptographic keys in the keystore 208 to prevent a malicious or compromised requester from successfully reusing an old sRA. In the embodiment shown in Figure 8, the security logic 202 preferably updates the cryptographic keys associated with each supported requester. generation (Generation:G) Implement Field 800. generation Field 800 is which of the encryption keys generation Identify whether two cryptographic keys will be used. generation (For example, key generation Assuming that only A and B are supported, keystore 208 will have the key for each supported requester. generation It may include Key1 and Key2 for A and B respectively. Therefore, the key store 208 may contain, for a given requester, the keys generationKey1A and Key2A, which are keys to be used in A, and key generation Includes Key1B and Key2B, which are keys to be used in B.

[0050] This arrangement, at a certain point in time, generation Field 800 is, for example, a key generation This will result in a value of b'0' representing A. As a result, the security logic 202 will select Key1A and Key2A (for example, using the multiplexer 802) for the encryption engine 204 to use when generating the encryption field 522 of the sRA520. At different points in time, generation Field 800 is, for example, a key generation This will result in a value of b'1' representing B. generation Field 800 is key generation Based on the indication of B, the security logic 202 will select Key1B and Key2B (for example, using the multiplexer 802) for the encryption engine 204 to use when generating the encryption field 522 of the sRA520. In either case, generation The value of field 800 is added to the encrypted output by the encryption engine 204. generation Placed within field 804, the encrypted field 522 of sRA520 is obtained. Note that in the shown embodiment, the encryption engine 204 is configured to generate a 42-bit cipher rather than the 43-bit second cipher 710 in Figure 7. In at least one implementation, this result can be achieved by reducing the length of the host field 506 from 12 bits to 11 bits.

[0051] In response to the receipt from the requester at request address 810, along with a memory access request, the security logic 202 performs the following actions at request address 810 generation Based on field 804, the key to be used to decrypt the request address 810 is selected (for example, using the multiplexer 812). The security logic further preferably uses the following for the request address 810 generationKey identified in Field 804 generation is a valid key generation The system includes a comparator 812 that detects whether the request remains false, and if not, causes the security logic 202 to reject the request address 810 as false.

[0052] Referring to Figure 9, in one embodiment, the processor 102 is key generation A high-level logic flowchart of an exemplary process for implementing it is shown. For ease of understanding, the process presented in Figure 9 is key generation Two alternating keys, referred to as A and B. generation This approach is explained by referring to the implementation of security logic 202 shown in Figure 8.

[0053] As shown, the process in Figure 9 starts at block 900, and then the security logic 202 of processor 102 processes the current key generation to key generation The process then proceeds to block 901, which indicates to initialize as A. The process then proceeds to security logic 202, which uses the current key generation (For example, key generation A) The process proceeds to block 902, which indicates the generation of two different keys (e.g., Key1A and Key2A) to be used in generating the sRA520 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. In addition, in block 902, the security logic 202 generates the keys generation A is the current key applicable to the requester. generation The value of b'0' to represent that generation Set to field 800. Key generation A is the current key generation While remaining in this state, the encryption engine 204 and decryption engine 206 of the security logic 202 generationUsing the keys associated with A, namely Key1A and Key2A, generate the sRA520 to be transmitted to the requester, decrypt the request address received from the requester, and the key generation The request address generated with the key for B is rejected (block 904).

[0054] In decision block 906, processor 102 gives the requester a new key generation Determine whether or not to use it. For example, in some embodiments or use cases, the processor 102 determines, at least partially, a new key based on the remapping of part or all of the address space previously allocated to the requester (or the LPAR to which the requester is assigned). generation It may be determined to use this. In some embodiments or use cases, the processor 102 determines a new key for the requester, at least in part, based on a software command. generation It may be determined to initiate. In some embodiments or use cases, the processor 102 determines, at least in part, the attributes of the encryption algorithm employed by the encryption engine 204, generation The frequency of changes can be determined. If processor 102 does not make a positive determination in block 906, the process returns to the described block 904. However, if processor 102 makes a positive determination in block 906, the process returns to the security logic 202 of processor 102, which determines the new current key. generation (For example, key generation During B), the process proceeds to block 908, which indicates the generation of two different keys (e.g., Key1B and Key2B) to be used in generating sRAs520 for the requester. As described above, the security logic 202 may generate keys using the key generation logic 210. In addition, in block 908, the security logic 202, generation Field 800 is a current key that can be applied to the requester. generation The associated value (for example, key) generation Set to the value of b'1' for B. Security logic 202 additionally, for example, generation The previous key, specified by the value identified in field 804. generation (For example, key generation A) A request to invalidate the conversion for all sRAs in block 910 is sent to the requester. In response to the request to invalidate the conversion, a non-malicious or uncompromised requester sends the previous key generation (For example, key generation A) This would invalidate any VA to sRA conversions within the ATC220 that reference the sRA generated during that process.

[0055] As shown in blocks 912-916, following the issuance of a conversion invalidation request and until an acknowledgment of the requested invalidation is received from the requester (block 914), or until the timeout period has elapsed (block 916), the security logic 202 generates the current key to generate the sRA. generation (For example, key generation The key for B) is used exclusively, but in order to decrypt the requested address generation A or generation Use the key for B. The previous key will be used until invalidation is acknowledged or the timeout period expires. generation (For example, key generation By continuing to support the request address in A), security logic 202, from the requester's perspective, is key generation Ensure a seamless and transparent transition between the two. In response to the reception of an invalidation acknowledgment by security logic 202 or the expiration of the timeout period, the process returns to block 904. As a result, the encryption engine 204 and decryption engine 206 of security logic 202 use the current key. generation The key associated with (for example, key generation Using only Key1B and Key2B of B, the sRA520 transmitted to the requester is generated, and the request address received from the requester is decoded. In addition, the security logic 202 uses comparator 812 generation Based on the detection of a discrepancy between the contents of fields 800 and 804, generation Non-current keys in field 804 generation It rejects any incoming request address that identifies the key. In this manner, the security logic 202 also 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 Figure 9 continues with the described block 906 and subsequent blocks. In at least some embodiments, the previous key generation In response to the determination in block 916 that the timeout period has elapsed without receiving an acknowledgment from the requester regarding the invalidation of sRA, processor 102 may additionally reset the requester.

[0056] Referring now to Figure 10, a data flow diagram of an exemplary AES-based encryption process that may be used in the generation of sRA520 according to one embodiment is illustrated. Specifically, the illustrated example shows a modified mini-AES encryption process that may be performed by the first-stage AES-based encryption logic 702 or the second-stage AES-based encryption logic 708. In the illustrated embodiment of Figure 10, Key(n) is either the output of the exclusive OR operation 705 or 707 in Figure 7.

[0057] In the first round of the modified mini-AES encryption process, the encryption engine 204 first logically combines a 36-bit intermediate RA 700 or 706 with a 36-bit modified Key(n) by, for example, performing an XOR operation 1002. The resulting 36-bit working value is then placed in a matrix, for example, a 3x3 matrix where each matrix entry holds one of nine nibbles. The contents of the matrix can then be subjected to conventional matrix operations, including through a substitution step 1004, a row shift step 1006, and a column mixing step 1008.

[0058] In the second round of the modified mini-AES encryption process 1000, the encryption engine 204 logically combines the 36-bit working value with the modified 36-bit Key(n) again, for example, by performing an XOR operation 1010. The resulting 36-bit working value is then subjected to another round of matrix operations, including a substitution 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 the conventional mini-AES encryption process and serves to further protect the sRA. The resulting 36-bit value can then be used as the cryptographic 704 or 710, as previously described in Figure 7.

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

[0060] In at least one embodiment, the processor receives a first request from a requester, which includes a virtual address. 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. Based on receiving a second request that identifies the requested address, the processor decrypts the requested address and verifies it as an encrypted secure real address. Based on verifying the requested address as an encrypted secure real address, the processor enables access to the data processing system resource identified by the real address. The use of encrypted secure real addresses provides enhanced security and generally requires a smaller footprint for implementation compared to table-based real address verification methods.

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

[0062] In some embodiments, at least a portion of the real addresses are encrypted using Advanced Encryption Standard (AES) based encryption. In some embodiments, encrypting at least a portion of the real addresses may, alternatively or additionally, involve generating a hash of at least a portion of the real addresses. Using strong encryption techniques such as AES offers the advantage of enhanced security, while using hashes offers the advantage of high performance.

[0063] In some embodiments, the processor avoids encrypting the lower bits of the actual address used to identify the address in the memory page. By not encrypting the complete actual address (e.g., 64 bits), encryption is simplified and performance is improved.

[0064] In some embodiments, encryption can be further enhanced 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 requester's process address space identifier and / or bits from the requester identifier. In some embodiments, the additional data may, alternatively or additionally, include a read-only field indicating whether the requester's access to the real address is read-only. In some embodiments, the additional data may include a key that identifies which of several keys was used to encrypt the real address. generation May include fields.

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

[0066] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, but is 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 preferred combination of those described above. A non-exclusive list of more specific examples of computer-readable storage media includes: 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), compact disc read-only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any preferred combination of those described above. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0067] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external 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 include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and transfers those computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0068] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk® or C++, and conventional 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 wide area network (WAN), or this connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, to carry out aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute a computer-readable program instruction by personalizing the electronic circuit using state information of the computer-readable program instruction.

[0069] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block in 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.

[0070] These computer-readable program instructions can be provided to the processors of general-purpose and dedicated computers, or other programmable data processing devices, to generate a machine, and as a result, instructions executed via the processor of a computer or other programmable data processing device create means for implementing functions / operations identified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions can also be stored in computer-readable storage media that can instruct computers, programmable data processing devices, and / or other devices to function in a particular manner, and as a result, computer-readable storage media having instructions stored therein comprises a product containing instructions that implement modes of functions / operations identified in one or more blocks of a flowchart and / or block diagram.

[0071] Computer-readable program instructions may be loaded onto a computer, other programmable data processing device, or other device to execute a series of operational steps on the computer, other programmable device, or other device, thereby generating a computer implementation process in which the instructions executed on the computer, other programmable device, or other device implement the functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[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 a flowchart or block diagram 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 described in a block may be performed in an order different from that shown in the drawings. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or blocks may be executed in reverse order depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or a combination of dedicated hardware and computer instructions.

[0073] While the present invention has been specifically described with reference to one or more preferred embodiments, it will be understood by those skilled in the art that various modifications in form and detail can be made therein without departing from the spirit and scope of the appended claims. For example, while examples of addresses and address fields of certain lengths have been discussed, those skilled in the art will understand that the present invention described herein is not limited to exemplary address and address field lengths. In addition, it is important to note that the described invention can be employed in both virtualized and non-virtualized environments. For example, in various embodiments or use cases, the requester may be assigned to a VM, hypervisor, or bare-metal OS. Furthermore, while embodiments have been described with reference to data processing hardware that directs specific functions, it should be understood that the present invention can be alternatively 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 perform such functions. Where adopted herein, “storage device” is specifically defined to include only statutory products and exclude the signaling medium itself, the transient propagating signals themselves, and the energy itself.

[0074] The diagrams and written descriptions relating to specific structures and functions described above are not presented to limit the scope of what the applicant has invented or the scope of the attached claims. Rather, the diagrams and written descriptions are provided to instruct any person skilled in the art on how to create and use the invention for which patent protection is sought. A person skilled in the art will understand that, for clarity and understanding, not all features of commercial embodiments of the invention are described or shown. A person skilled in the art will also understand that developing actual commercial embodiments incorporating aspects of the invention will require a number of implementation-specific decisions to achieve the developer's ultimate goals for such commercial embodiments. Such implementation-specific decisions may include, but are not limited to, compliance with system-related, business-related, government-related, and other constraints, which may vary by particular implementation, location, and time. While the developer's work may be complex and time-consuming in an absolute sense, such work will nevertheless be routine for a person skilled in the art who benefits from this disclosure. It should be understood that the invention disclosed and taught herein is capable of numerous and varied 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. (Other possible items) (Item 1) A method of data processing in a data processing system equipped with 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 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; The step of the processor 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 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]. (Item 2) The data processing method according to item 1, 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. (Item 3) The data processing method according to item 1, 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. (Item 4) The data processing method according to item 1, 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. (Item 5) The data processing method according to item 1, wherein the step of encrypting at least a portion of the actual address includes a step of avoiding encrypting the lower bits of the actual address that are used to identify the address in the memory page. (Item 6) The data processing method according to item 1, further comprising the step of combining additional data with at least a portion of the actual address prior to the encryption step. (Item 7) The data processing method described in item 6, 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. (Item 8) The data processing method described in item 6, wherein the additional data includes a read-only field indicating whether the access to the actual address by the requester is read-only. (Item 9) The data processing method described in item 6, wherein the additional data includes a key generation field that identifies which key was used from among multiple keys to encrypt the actual address. (Item 10) 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, to encrypt at least a portion of the actual address to obtain an encrypted secure actual address, and to 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 A data processing system equipped with the following features. (Item 11) The data processing system described in item 10 includes a procedure for receiving a Peripheral Component Interconnection Express Address Translation Service (PCIe ATS) protocol request, 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. (Item 12) The data processing system according to item 10, wherein the procedure for encrypting at least a portion of the real address includes a procedure for encrypting at least a portion of the real address using Advanced Encryption Standard (AES) based encryption. (Item 13) The data processing system according to item 10, 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. (Item 14) The data processing system described in item 10, wherein the procedure for encrypting at least a portion of the actual address includes a procedure for avoiding the encryption of lower bits of the actual address used to identify the address in the memory page. (Item 15) The aforementioned processor is: A procedure to combine additional data with at least a portion of the actual address, prior to the encryption procedure. A data processing system as described in item 10, further configured to perform the following: (Item 16) The data processing system described in item 15 includes at least one of the following sets: bits from the process address space identifier of the requester and bits from the requester identifier. (Item 17) The data processing system described in item 15 includes a read-only field indicating whether the access to the actual address by the requester is read-only. (Item 18) The data processing system described in item 15 includes a key generation field that identifies which of several keys was used to encrypt the actual address. (Item 19) System memory coupled to the aforementioned processor; and The requester coupled to the processor via the bus A data processing system as described in item 10, further comprising the features described above. (Item 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 to determine the actual address corresponding to the virtual address based on the first request, to encrypt at least a portion of the actual address to obtain an encrypted secure actual address, and to 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 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 program product that executes an action. (Item 21) The procedure for receiving the first request includes a procedure for receiving a Peripheral Component Interconnection Express Address Translation Service (PCIe ATS) protocol request, as described in item 20 of the program product. (Item 22) The procedure for encrypting at least a portion of the real address includes a procedure for encrypting at least a portion of the real address using Advanced Encryption Standard (AES) based encryption, as described in item 20. (Item 23) The program product described in item 20, wherein the procedure for encrypting at least a portion of the real address includes a procedure for generating a hash of the at least portion of the real address. (Item 24) The program product described in item 20, wherein the procedure for encrypting at least a portion of the actual address includes a procedure for avoiding the encryption of the lower bits of the actual address used to identify the address in the memory page. (Item 25) When the aforementioned program code is executed, it will send the following to the processor: A procedure to combine additional data with at least a portion of the actual address, prior to the encryption procedure. The program product described in item 20 that causes the program to run.

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 method for data processing 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