TWI804332B - Method, system and program product for data processing - Google Patents

Abstract

A processor receives, from a requestor, a first request containing 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 a cryptographic secure real address, and returns the cryptographic secure real address to the requestor. Based on receiving a second request specifying a request address, the processor decrypts the request address to validate the request address as the cryptographic secure real address. Based on validating the request address as the cryptographic secure real address, the processor allows access to a resource of the data processing system identified by the real address.

Description

Data processing method, system and program product

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

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 data processing systems, the hardware resources of the data processing system may be logically partitioned into multiple resource sets, each resource set being controlled by a respective one of multiple, possibly heterogeneous, operating system instances. Operating systems execute in parallel on this common hardware platform in their respective logical partitions (LPARs) under the control of system firmware, which is commonly referred to as a virtual machine monitor (VMM) or hypervisor. Thus, the hypervisor allocates to each LPAR a disjoint subset of the data processing system's resources, and each operating system instance in turn directly controls its different set of allocatable resources, such as regions of system memory and IOAs.

In general, an IOA in a data processing system employs an I/O (or virtual) address space that is different from the real address space used to address system memory in the data processing system. Therefore, address translation is used to translate addresses between the I/O address space of the data processing system and the real address space. In at least some earlier prior art data processing systems, all translations between I/O address space and real address space were performed on the processor die. Therefore, I/O and A real address translator can be used to restrict an IOA to only a subset of real addresses to which it is permitted to access.

More recently, at least some I/O standards, such as Peripheral Component Interconnect Express (PCIe), have adopted an Alternative Address Translation Service (ATS), where an IOA can request a translation for an I/O address and, in response, bridge The device receives the corresponding real address. The IOA may then cache the real address in an address translation cache (ATC), and then issue one or more memory access requests specifying the real address to the host bridge. Enables IOA to utilize real addresses for memory access requests while improving latency for accesses that reference frequently or recently accessed addresses, potentially exposing host system memory to malicious or compromised I/O devices access, resulting in significant security issues. At least some prior art systems ameliorate this security issue in part by performing real address verification on incoming I/O memory access requests to ensure that each IOA only accesses authorized real address pages. However, this address translation service implementation has poor performance and has proven to be expensive to implement in terms of the memory footprint required to store the tables conventionally used to perform true address verification. These shortcomings are exacerbated in implementations where real address authentication employs fine-grained authentication, eg, based on both Requester Identifier (RID) and Process Address Space Identifier (PASID).

In at least one embodiment, a data processing system provides improved I/O security while supporting address translation services for an attached device.

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

In at least one embodiment, a processor receives a first request including a virtual address from a requester. 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 a cryptographically secure real address, and transmits the cryptographically secure real address Back to the requester. Based on receipt of a specified A second request is made for one of the request addresses, the processor decrypts the request address to verify the request address as the cryptographically secure real address. Based on validating the requested address as the cryptographically secure real address, the processor permits access to a resource of the data processing system identified by the real address. The use of a cryptographically secure real address provides improved security and generally requires a smaller implementation footprint than table-based real address authentication methods.

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

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 the at least a portion of the real address. Utilizing strong encryption techniques such as AES has the advantage of improved security, and utilizing hashing has the advantage of high performance.

In some embodiments, the processor refrains from encrypting the lower order bits of the real address specifying an address within a memory page. By not encrypting the full real address (eg, 64 bits), encryption is simplified and performance is improved.

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

100: Data Processing Systems

102a: Processor

102n: processor

104: System mesh architecture

110: processor core

112: Cache memory

114: Integrated memory controller

116a: Off-chip system memory

116n: off-chip system memory

118: Mesh Architecture Interface

120: host bridge

120a: host bridge

120k: host bridge

120m: host bridge

120v: host bridge

122a: Bus at the local end

122k: local bus

122m: Bus at the local end

122v: local bus

124a: I/O mesh architecture

124k: I/O mesh architecture

124m: I/O mesh architecture

124v: I/O mesh architecture

130:IOA

130a: I/O Adapter

130k: I/O Adapter

130l: I/O Adapter

130m: I/O Adapter

130v: I/O Adapter

130w: I/O adapter

140: Attach device interface

142: Attachment device

200: I/O memory management unit

202: Safety logic

204: encryption engine

206: Decryption engine

208: key storage area

210: key generation logic

212: Real Address Verification (RAV) logic

220:Address translation cache memory

300: block

302: block

304: block

305: block

306: block

308: block

310: block

312: block

314: block

316: block

400: block

402: block

404: block

406: block

408: block

410: block

412: block

414: block

416: block

500:RA

502: high-order bit field

504: low-order bit field

506: host field

510: entropy mixer

512: encryption logic

514: Decryption logic

516: Entropy Demixer

520: Encrypt sRA

522: encrypted field

530: Decrypted RA

532: high-order bit field

534:Decrypted host field

600:Translate context field

602: Read-only (RO) field

700: First Intermediate RA

702: The first stage is based on the encryption logic of the Advanced Encryption Standard

704: first password

705: Exclusive OR (XOR) operation

706:Second Intermediate RA

707: XOR operation

708: The second stage is based on the encryption logic of the Advanced Encryption Standard

710: second password

800: generate fields

802: multiplexer

804: generate fields

810: request address

812: Comparator

900: block

901: block

902: block

904: block

906: block

908: block

910: block

912: block

914: block

916: block

1002: XOR operation

1004: replace step

1006: column shift step

1008: line mixing step

1010: XOR operation

1012: replace step

1014: column shift step

1016: line mixing step

1018: XOR operation

1 is a high-level block diagram of an exemplary data processing system according to one embodiment; FIG. 2 is a more detailed block diagram of a host bridge and an I/O adapter (IOA) according to one embodiment; FIG. A high-level logic flow diagram of an exemplary process by which the processor of an embodiment provides a cryptographically secure real address (sRA) to a requester; FIG. 4 is a memory access request by which a processor handles a requester according to one embodiment A high-level logic flow diagram of an exemplary program; FIGS. 5A - 5B illustrate real address encryption to obtain a secure real address and secure real address decryption to obtain an original real address according to one embodiment; FIG. 6 Depicts the contents of an exemplary host field of a real address according to one embodiment; FIG. 7 is a high-level data flow diagram of an exemplary process for encrypting a real address to obtain a cryptographically secure real address, according to one embodiment; Figure 8 is a fragmentary view illustrating a portion of the security logic of a processor supporting key generation according to one embodiment; Figure 9 is a high-level logic flow diagram of an exemplary process by which a processor implements key generation according to one embodiment and FIG. 10 is a data flow diagram of an exemplary AES-based encryption procedure that may be used to generate a cryptographically secure true address, according to one embodiment.

Referring now to the figures, and in particular to FIG. 1 , a high-level block diagram of an exemplary data processing system 100 is depicted 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 through 102n , each processor coupled for communication with system mesh architecture 104 , the system A mesh architecture may include one or more bus or switched communication links. In alternative embodiments, a data processing system with a single processor 102 may be utilized.

In the depicted embodiment, each processor 102 is preferably implemented as a single integrated circuit die having a semiconductor substrate, where the integrated circuits are fabricated as known in the art. As shown, each processor 102 includes a plurality of processor cores 110 that process data by executing and/or processing program code, which may include, for example, software and/or firmware and associated data, if present. This code may include, for example, a hypervisor, to which the hypervisor may allocate one or more operating system instances of a logical partition (LPAR), and an application. Processor 102 further includes cache memory 112 , which provides one or more levels of relatively low-latency temporary storage for instructions and data retrieved from lower levels of the data storage hierarchy. Additionally, processor 102 includes an integrated memory controller (IMC) 114 that controls access to associated ones of off-chip system memories 116a - 116n . The processor 102 accesses the system memory 116 using a real address (RA) in the real address space. In various embodiments, real addresses may have different lengths, such as 32 bits, 64 bits, and so on.

Each processor 102 further includes a fabric interface (FIF) 118 through which the processor 102 communicates with the system fabric 104 , and supports input/output adapters (IOAs) 130a through 130l or 130m through 130w . One or more (and preferably a plurality) of host bridges (HB) 120a to 120k or 120m to 120v for outgoing communications. The IOA 130 can be, for example, a network adapter, a storage device controller, a display adapter, a peripheral adapter, and the like. In its processing, IOA 130 references I/O addresses (also known as virtual addresses (VA)) in VA space. In various embodiments, VAs may be of different lengths, such as 32 bits, 40 bits, 48 bits, 52 bits, 64 bits, etc. The length of VA employed by IOA 130 may be different (ie, shorter or longer) than the length of RA employed by processor 102 .

In various embodiments, host bridge 120 may be communicatively coupled to IOA 130 directly or indirectly. For example, in the illustrated embodiment, host bridges 120a , 120k , 120m , and 120v provide interfaces to local buses 122a , 122k , 122m , and 122v , respectively, to which IOA 130 can be directly connected or indirectly coupled Wait for the local bus. Therefore, the IOA 130a is optionally coupled to the local bus 122a via the I/O mesh 124a , which may include one or more switches and/or bridges. In a similar manner, IOAs 130k and 1301 are optionally coupled to local bus 122k via I/O mesh 124k , IOA 130m is optionally coupled to local bus 122m via I/O mesh 124m , and IOA 130v and 130w are optionally coupled to the local bus 122v via the I/O mesh structure 124v . In some embodiments, communication on one or more of the local buses 122 utilizes known I/O bus standards, such as the Peripheral Component Interconnect (PCI) or PCI Express (PCIe) standards. In some embodiments, one or more of the local bus bars 122 may use additional or alternative I/O bus bar standards.

As further depicted in FIG. 1 , one or more of processors 102 (eg, processor 102a ) may further include an attachment device interface (ADI) 140 that supports attachment of an attachment device 142 . In some embodiments, attachment device 142 may be, for example, an accelerator that enables processor 102 to offload one or more processing functions, such as data encryption/decryption, data compression/decompression, matrix operations, data streaming management etc. Attachment device 142 may also refer to VA space, which may be different or the same as the VA space utilized by IOA 130 , when performing its processing.

Those of ordinary skill in the art will appreciate that the architecture and components of the data processing system may vary between embodiments. For example, other devices and interconnects may alternatively or additionally be used. Accordingly, the exemplary data processing system 100 presented in FIG. 1 is not intended to imply architectural limitations with respect to the claimed invention.

Referring now to FIG. 2 , depicted is a more detailed block diagram of host bridge 120 and I/O adapter 130 according to one embodiment. In the depicted example, host bridge 120 includes I/O memory management unit (IOMMU) 200 configured to provide a VA referenced by a requester, such as IOA 130 , to be available to Translations of RAs that 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 the requester and decrypt addresses received from the requester. In the illustrated embodiment, security logic 202 includes: encryption engine (EE) 204 , which is used to perform encryption to generate secure real address (sRA); decryption engine 206 , which is used to decrypt the received request address; and the key storage area 208 , which is used to store the key used in encryption and decryption. In at least some embodiments, host bridge 120 may utilize separate keys for each requester it supports. For example, assuming host bridge 120 is a PCIe host bridge, host bridge 120 may implement individual gold for each PCIe Requester Identifier (RID) or for each combination of RID and Process Address Space Identifier (PASID). key. In at least some embodiments, security logic 202 additionally includes: key generation logic 210 for generating encryption keys in key storage area 208 ; and optional Real Address Verification (RAV) logic 212 for Used to verify the real address of the request received by the host bridge 120 from the requester.

FIG. 2 additionally illustrates that a requestor such as IOA 130 may include address translation cache (ATC) 220 . Address translation cache 220 may include a plurality of entries associating recently and/or frequently accessed VAs with corresponding secure RAs (sRAs) received from host bridge 120 .

Although not specifically illustrated in FIG. 2 , it should be appreciated that ADI 140 of FIG. 1 may be constructed similarly to host bridge 120 . For example, ADI 140 may include IOMMU 200 and security logic 202 . Like IOA 130 , attachment device 142 may also include ATC 220 for caching VA to sRA translations obtained from ADI 140 .

Referring now to FIG. 3 , a high-level logic flow diagram of an exemplary process by which processor 102 provides a cryptographically secure RA (sRA) to a requester is illustrated, in accordance with one embodiment. In some implementations, the process of FIG. 3 may be performed by the host bridge 120 providing the cryptographic sRA to the IOA 130 . The same procedure may alternatively or additionally be employed by ADI 140 to provide sRA to attachment device 142 .

The process of FIG. 3 begins at block 300 , and then proceeds to block 302 , which illustrates processor 102 receiving a translation request from an associated requester specifying a virtual address to translate. In some embodiments, the translation request may be, for example, a PCIe ATS translation request. In response to receiving the translation request, processor 102 translates VA to RA in the real address space of data processing system 100 , eg, using IOMMU 200 . Processing continues from block 304 to optional block 305 , which illustrates that the processor 102 prepares the RA for encryption. In the illustrated embodiment, preparing the RA for encryption at block 305 includes multiple steps, including excluding from the encryption a few low-order bits of the RA designating a particular address within a given memory page ( block 306 ). For example, assuming the length of the RA is 64 bits and the processor 102 allocates a 2MB memory page for the requester, the 21 low order bits of the RA are excluded from encryption at block 306 . As should be appreciated, if the processor 102 avoids encrypting all bits of RA, the encryption procedure is simplified and the encryption performance is improved. At block 305, the truncated RA is optionally padded with a host field including one or more extra bits (block 308 ). Different embodiments of the host field are described below with reference to FIGS . 5A and 6 . Furthermore, 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 , bit positions are reconfigured in the intermediate RA in a fixed predetermined manner.

The procedure of FIG. 3 continues from block 305 to block 312 , which illustrates that processor 102 encrypts the RA (the RA received from IOMMU 200 , or the intermediate RA obtained after block 305 if block 305 is implemented. ) to obtain a cryptographically secure RA (SRA). In some embodiments, the encryption depicted at block 312 may include 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, encryption may alternatively or additionally include the encryption engine 204 encrypting the RA with one or more keys. If key-based encryption is performed, it is preferred that the encryption engine 204 utilize a different key for each requester (or for each combination of RID and PASID). Examples of possible encryption algorithms that may be employed are described below with reference to FIGS. 7 and 10 . The processor then provides the sRA resulting from the encryption performed at block 312 to the requester (block 314 ). In at least some embodiments, 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 (eg, in the ATC 220 ) to facilitate future use of the sRA in memory access requests. Following block 314 , processing of the translation request by processor 102 ends at block 316 .

Referring now to FIG. 4 , depicted is a high-level logic flow diagram of an exemplary process by which processor 102 handles memory access requests from requesters, according to one embodiment. In some implementations, the process of FIG. 4 may be performed by the host bridge 120 receiving memory access requests from the IOA 130 . The same program may alternatively or additionally be executed by ADI 140 in response to receiving a memory access request from attached device 142 .

The process begins at block 400 and then proceeds to block 402 , which illustrates that the processor 102 receives a memory access request from a requester, such as the IOA 130 or the attached device 142 . A memory access request, which can typically be a read request requesting return of data or a write request requesting update of data, specifies the requested address to be accessed. In the case that the requester is not a malicious or compromised device, the request address will be the sRA, which was previously provided to the requester by the processor 102 by the procedure of FIG. 3 . However, where 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 address ranges that the requester is authorized to access.

In response to receiving the memory access request, the processor 102 decrypts the requested address (block 404 ). For example, if the encryption engine 204 uses a hash function to generate sRA, the decryption engine 206 can use the corresponding inverse hash function to decrypt the request address at block 404 . Alternatively, if the encryption engine 204 generates the sRA using a key-based encryption function, the decryption engine 206 can decrypt the request address at block 404 using the same key that was used to encrypt the sRA. Similarly, the decryption engine 206 can access the relevant key in the key storage area 208 based on the requester's identification code (or RID/PASID combination), which is preferably provided by the requester in the memory access request or in combination with Memory access requests are communicated together, either partially or fully implied by the position of the requestor on the connecting I/O bus. Assuming that the bits of the middle RA were shuffled at block 310 of FIG . reordering (block 406 ).

At block 408 , the 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 where processor 102 adds a host field to fill in the RA at block 308 of FIG . bit matches the host field added to RA at block 308 . The check at block 408 may alternatively or additionally include RAV logic 212 performing a real address verification of some or all of the RA bits of the decrypted request address. At block 410 , the processor 102 determines whether one or more checks performed at block 408 were successful or all were successful. Based on the determination at block 410 that one or more checks performed at block 408 were all successful, the request address is confirmed to be the proper sRA, and processor 102 allows access to one of the data processing systems 100 identified by the decrypted RA. Access to resources (eg, locations in system memory 116 ) (block 412 ). However, if processor 102 determines at block 410 that one or more checks performed at block 410 were unsuccessful, processor 102 does not allow access to the resource of data processing system 100 identified by the decryption request address (if Exists) the requested access (block 414 ). Additionally, at block 414 , the processor 102 stops the operation of the requester to stop the requester from generating a potentially malicious memory access request. Processor 102 may also optionally reset (restart) the requester to restore the requester to a known stable state from which the requester will again be permitted to issue memory access requests. After block 412 or block 414 , the process of FIG. 4 ends at block 416 .

Referring now to FIG. 5A , an exemplary procedure by which the processor 102 encrypts a real address (RA) to obtain a secure real address (sRA) according to one embodiment is illustrated. In the depicted example, security logic 202 receives RA 500 from IOMMU 200 . In the depicted example where processor 102 supports 64 bits of 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 requestors, such as IOA 130 and attached device 142 , typically do not need to address (or are limited to addressing) the full RA space of data processing system 100 . The RA 500 includes a high-order bit field 502 and a low-order bit field 504 . In the depicted example, the boundary between high-order bit field 502 and low-order bit field 504 is selected to correspond to memory allocated (e.g., by the operating system or hypervisor software) to the associated requestor The size of the body page. In this example, the 21-bit length of the low-order bit field corresponds to a memory page size of 2MB. As illustrated, processor 102 preferably avoids encrypting the contents of low-order bit fields because, by definition, it is not a security threat for a requester to access or modify the contents of one of its own allocated memory pages. By excluding the low-order bit field 504 from encryption, the encryption performed by the encryption engine 204 is simplified and encryption performance is improved.

As discussed above with reference to block 308 of FIG. 3 , security logic 202 may pad truncated RA 500 (now including only high-order bit field 502 ) with the desired number of bits including host field (HF) 506 to obtain Encrypt the desired number of bits. For example, in the illustrated example, the host field 506 is chosen 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 can be encoded within the host field 506 . For example, FIG. 6 depicts an exemplary embodiment in which the host field 506 includes a translation context field 600 in which the processor 102 records the translation context for VA to sRA translation. For example, in embodiments where the processor 102 and the requestor communicate using the 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, the translation context field 600 includes a concatenation of the associated RIDs and PASIDs. 6 further illustrates that processor 102 may optionally include a read-only (RO) field 602 in host field 506 that specifies whether RA 500 is mapped to a memory page identified, for example, in page protection information maintained in IOMMU 200 as ROM pages. In embodiments where the host field 506 includes the RO field 602 , the checks performed by the security logic 202 at block 408 include checking whether the memory access request is a write-type request and whether the RO field 602 is set to Indicates a read-only memory page. In this case, the security logic 202 fails the check at block 410 of FIG. 4 . In some embodiments, the host field 506 may alternatively or additionally include a key generation field, as discussed further below with reference to FIGS . 8-9 .

Referring back to FIG. 5A , after filling the high-order bit field 502 with the host field 506 , the entropy mixer 510 within the encryption engine 204 can optionally rearrange the order of at least some bit positions of the 43-bit intermediate RA to increase entropy . In general, this bit position reordering involves distributing the lower order bits of the high order bit field 502 among the 43 bit positions of the middle RA, which tends to have a higher number of bits in the bit values between the RAs. High variability. The intermediate RA is then encrypted by the encryption logic 512 within the encryption engine 204 to obtain a 43-bit encrypted field 522 . The encrypted field 522 is serially concatenated with the unencrypted 21-bit low-order field 504 to form a cryptographic sRA 520 , which the processor 102 can pass without exposing the actual corresponding RA to discovery by the requester. This cryptographic sRA is securely transmitted back to the requester.

Referring now to FIG. 5B , an exemplary procedure for decrypting the sRA 520 to obtain the corresponding real address is illustrated, according to one embodiment. Decryption logic 514 within decryption engine 206 decrypts encrypted field 522 in response to receiving sRA 520 returned to security logic 202 , eg, in a memory access request. An entropy de-mixer (de-mixer) 516 within the decryption engine 206 reverses the bit shuffling performed by the entropy mixer 510 to obtain a high-order bit field 532 and a decrypted host field 534 , which are identical to the low-order bit fields Together the fields 504 form a decrypted RA 530 . As mentioned 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 authorized real address of the requester. Furthermore, security logic 202 may alternatively or additionally utilize RAV logic 212 to check for RA bits found in high-order bit field 532 and low-order bit field 504 .

Referring now to FIG. 7 , a high-level data flow diagram illustrating an exemplary process by which processor 102 may encrypt a real address to obtain a cryptographically secure real address (sRA) is illustrated, according to one embodiment. In particular, FIG. 7 illustrates a two-stage key-based encryption procedure that is one of many possible encryption techniques that may be applied by the encryption engine 204 ; in other embodiments, other encryption techniques may be employed instead.

In the depicted encryption technique, the 31-bit high-order bit field 502 of FIG . 5A is divided into 8 nibbles labeled, labeled HO1 to HO8 from highest order to lowest order (where HO2 consists of only 3 short nibble of ones bits). In this example, nibbles HO1 and HO2 are reserved for the second stage of encryption and are not processed by entropy mixer 510 . The bit positions of the remaining 36 bits (3 nibbles of the host field 506 and 6 nibbles of the high order field 502 ) are mixed in a predetermined pattern by the entropy mixer 510 to generate the description The 36-bit first intermediate RA 700 is nine 4-bit nibbles.

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") and additional data to obtain a modified first encryption key. In the depicted example, this additional data is a requester-related identifier, such as a RID or a concatenated concatenation of RID and PASID associated with an address translation request. 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, eg, 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 small AES-based encryption scheme employing a 36-bit key. One example of such a small AES-based encryption scheme is described below with reference to FIG. 10 . The output of the first stage AES-based encryption logic 702 is a 36-bit first password 704 , which is specified as nine 4-bit nibbles.

The encryption engine 204 reserves the seven highest-order bits of the first password 704 for subsequent use. The encryption engine 204 forms the second intermediate RA 706 by concatenating the 29 lower-order bits of the first password 204 with the nibbles HO1 and HO2 reserved from the high-order bit field 502 .

In the second stage of encryption, encryption engine 204 logically combines (eg, using XOR operation 707 ) a second encryption key ("Key2") with additional data to obtain a modified second encryption key. As noted above, this additional data may be a requester-related identifier, such as a RID or a concatenated concatenation of RID and PASID associated with an address translation request. The encryption engine 204 then encrypts the second intermediate RA 706 with a modified second encryption key (eg, a 36-bit key), such as with 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 circuitry may be reused. The output of the second stage AES-based encryption logic 708 is a 36-bit second cipher 710 specified as nine 4-bit nibbles. The encryption engine 204 may then form the 43-bit encrypted field of the sRA 520 by sequentially concatenating the 7 highest-order bits of the first password 704 retained after the first-stage encryption with the 36-bit second password 710 522 . As illustrated in FIG. 5A , security logic 202 then appends unencrypted 21-bit low-order bit field 504 to encrypted field 522 to form full 64-bit sRA 520 .

Referring now to FIG. 8 , a partial view of the portion of the security logic 202 of FIG. 2 that supports key generation is depicted, according to one embodiment.

Over time, the 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 ( LPAM). When reallocating a page of memory, the processor 102 will generally invalidate the corresponding translation entry in its IOMMU 200 and in the ATC 220 of its attached requestor, eg, by sending a translation invalidation request. If the requester receiving the translation invalidation request is not malicious and is error-free, the requester will invalidate each instructed translation in its ATC 220 in accordance with the translation invalidation request of the processor 102 . However, if the requester is malicious or compromised, the requester can respond to the translation invalidation request without invalidating the translations in its ATC 220 , and can instead keep the stale sRA and try to use the stale sRA again to attempt access later The portion of the real address space that is not currently allocated to this requestor.

In at least some embodiments, security logic 202 is configured to transparently update the use of encryption keys in key store 208 to prevent malicious or compromised requesters from being able to successfully re-use an outdated sRA. In the embodiment of FIG. 8 , security logic 202 preferably implements a separate generation (G) field 800 associated with the encryption key assigned to each supported requestor. Generate field 800 specifies which encryption key will be used for generation. For example, assuming that only two encryption key generations are supported (e.g., denoted as Key Generation A and B), the key storage area 208 may include, for each supported requestor, one for each of Key Generation A and B Key1 and Key2. Thus, the key store 208 includes keys Key1A and Key2A for use during key generation A and keys Key1B and Key2B for use during key generation B for a given requester.

With this configuration, at a certain point in time, the generation field 800 will have the value b"0", indicating, for example, key generation A. Accordingly, security logic 202 will select (eg, using multiplexer 802 ) Key1A and Key2A for use by encryption engine 204 in generating encrypted field 522 of sRA 520 . At various times, the generation field 800 will have the value b"1", indicating key generation B, for example. Based on generation field 800 indicating key generation B, security logic 202 will select (eg, using multiplexer 802 ) Key1B and Key2B for encryption engine 204 to use to generate encrypted field 522 of sRA 520 . In either case, the value of generation field 800 is placed in generation field 804 that is appended to the password output by encryption engine 204 to obtain encrypted field 522 of sRA 520 . It should be noted that in the illustrated embodiment, the encryption engine 204 is configured to generate a 42-bit password rather than the 43-bit second password 710 of FIG. 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.

In response to receiving the request address 810 together with the memory access request from the requester, the security logic 202 selects (e.g., using the multiplexer 802 ) the one to be used to decrypt the request address 810 based on the generation field 804 of the request address 810 key. The security logic additionally preferably includes a comparator 812 to detect whether the key generation specified by the generation field 804 of the request address 810 is still a valid key generation, and if not, cause the security logic 202 to Request address 810 is rejected as a pseudo address.

Referring now to FIG. 9 , a high-level logic flow diagram of an exemplary process by which processor 102 implements key generation is illustrated, according to one embodiment. For ease of understanding, the procedure presented in FIG. 9 , which employs two alternating keygenerations called keygenerations A and B, is described with reference to the implementation of the security logic 202 depicted in FIG .

As shown, the process of FIG. 9 begins at block 900 and then continues to block 901 , which illustrates that security logic 202 of processor 102 initializes the current key generation as key generation A. The program then continues to block 902 , which illustrates that the security logic 202 generates two different keys (e.g., Key1A and Key2A) for generating the sRA 520 for the requester during the current key generation (e.g., key generation A) . For example, security logic 202 may generate keys using key generation logic 210 such as linear feedback shift register (LFSR) or AES key generation logic. Additionally, at block 902 , the security logic 202 sets the generation field 800 to a value b"0" to indicate that key generation A is the current key generation applicable to the requester. Although key generation A is still the current key generation, the encryption engine 204 and decryption engine 206 of the security logic 202 utilize the keys associated with generation A (i.e., Key1A and Key2A) to generate the sRA 520 that is transmitted to the requester and The request address received from the requester is decrypted and the request address generated with the key used for key generation B is rejected (block 904 ).

At decision block 906 , processor 102 determines whether to use new key generation for the requester. For example, in some embodiments or use cases, the processor 102 may determine to utilize the new gold address space based at least in part on remapping some or all of the address space previously allocated to the requestor (or to the LPAR to which the requestor is allocated). key generation. In some embodiments or use cases, the processor 102 may determine to initiate new key generation for the requester based at least in part on the software command. In some embodiments or use cases, processor 102 may determine the frequency of key generation changes based at least in part on properties of the encryption algorithm employed by encryption engine 204 . If the processor 102 does not make an affirmative determination at block 906 , the process returns to block 904 , which has already been described. However, if the processor 102 makes an affirmative determination at block 906 , then the program continues to block 908 , which illustrates that the security logic 202 of the processor 102 generates two different keys (eg, Key1B and Key2B) for use in The sRA 520 for the requester is generated during a new current key generation (eg, Key Generation B). Security logic 202 may use key generation logic 210 to generate keys, as described above. Additionally, at block 908 , the security logic 202 sets the generation field 800 to the value associated with the current key generation applicable to the requester (eg, value b"1" for key generation B). The security logic 202 additionally sends translation invalidation requests to the requester for all sRAs in a previous key generation (e.g., key generation A), such as specified by the value specified in the generation field 804 (area block 910 ). In response to a translation invalidation request, a requester that is not malicious or compromised will invalidate any VA-to-sRA translations in its ATC 220 that reference an sRA generated during a previous key generation (eg, Key Generation A).

As indicated by blocks 912 through 916 , after a translation invalidation request is issued and until a response to the requested invalidation is received from the requester (block 914 ) or a timeout period has elapsed (block 916 ), the security logic 202 exclusively sRA is generated using the key used for the current key generation (eg, key generation B), but the request address is decrypted using the key used for generation A or generation B. Security logic 202 ensures seamless and seamless between key generation from the requester's perspective by continuing to support the request address in a previous key generation (e.g., key generation A) until invalidation is confirmed or a timeout period has elapsed. Transparency. In response to the security logic 202 receiving an invalid response or the timeout period has elapsed, the process returns to block 904 . Thus, the encryption engine 204 and decryption engine 206 of the security logic 202 only utilize 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 decrypt it from The request address received by the requester. Additionally, security logic 202 rejects any incoming request address specifying a non-current key generation in generation field 804 based on comparator 812 detecting a mismatch between the contents of generation fields 800 and 804 . In this way, the security logic 202 prevents reuse of any stale sRAs that would have been invalidated by the requester in response to the translation invalidation request issued at block 910 . After block 904 , the process presented in FIG. 9 continues at block 906 and subsequent blocks, which have been described. In at least some embodiments, in response to a determination that the timeout period at block 916 has elapsed without receiving an invalid response from the requester to the sRA used for previous key generation, the processor 102 may additionally reset the request device.

Referring now to FIG. 10 , depicted is a data flow diagram of an exemplary AES-based encryption process that may be used to generate sRA 520 , according to one embodiment. In particular, the depicted example illustrates a modified small AES encryption procedure that may be performed by either the first stage AES-based encryption logic 702 or the second stage AES-based encryption logic 708 . In the depicted embodiment of FIG. 10 , Key(n) is the output of mutex or 705 or 707 of FIG. 7 .

In the first round of the modified small AES encryption procedure, the encryption engine 204 first logically combines the 36-bit intermediate RA 700 or 706 with the 36-bit modified Key(n), eg, by performing an XOR operation 1002 . The resulting 36-bit working value is then placed in a matrix, such as a 3x3 matrix, where each matrix entry holds one of nine nibbles. The contents of the matrix may then undergo conventional matrix manipulations, including via a replace step 1004 , a column shift step 1006 , and a row blend step 1008 .

In the second round of the modified small AES encryption program 1000 , the encryption engine 204 again logically combines the 36-bit working value with the 36-bit modified Key(n), eg, by performing an XOR operation 1010 . The resulting 36-bit working value then undergoes another round of matrix manipulation, including a replace step 1012 , a column shift step 1014 , and an optional row blend step 1016 . It should be noted that the row mixing step 1016 is not performed in the conventional small AES encryption procedure and is used to further protect the sRA. The 36-bit value resulting from the illustrated process may then be used as a password 704 or 710 as previously described in FIG. 7 .

As described, in at least one embodiment, a data processing system provides improved I/O security while supporting address translation services for an attached device.

In at least one embodiment, a processor receives a first request including a virtual address from a requester. 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 a cryptographically secure real address, and transmits the cryptographically secure real address Back to the requester. Upon receiving a second request specifying a request address, the processor decrypts the request address to verify the request address as the cryptographically secure true address. Based on validating the requested address as the cryptographically secure real address, the processor permits access to a resource of the data processing system identified by the real address. The use of a cryptographically secure real address provides improved security and generally requires a smaller implementation footprint than table-based real address authentication methods.

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

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 the at least a portion of the real address. Utilizing strong encryption techniques such as AES has the advantage of improved security, and utilizing hashing has the advantage of high performance.

In some embodiments, the processor refrains from encrypting the lower order bits of the real address specifying an address within a memory page. By not encrypting the full real address (eg, 64 bits), encryption is simplified and performance is improved.

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

The present invention can be a system, a method and/or a computer program product. A computer program product may include one (or more) computer-readable storage media having computer-readable program instructions thereon to cause a processor to perform aspects of the present invention.

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 foregoing. 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 Compact Read-Only Memory (EPROM or Flash), Static Random Access Memory (SRAM), Portable Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD), Memory Stick, Soft Disk Magnetic disks, mechanical encoding devices such as punched cards or raised structures in grooves on which instructions are recorded, and any suitable combination of the foregoing. As used herein, the computer-readable storage medium itself should not be construed as a transitory signal, such as a wireless Electromagnetic waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses traveling through optical cables), or electrical signals transmitted by wires.

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

The computer readable program instructions for carrying out the operations 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 in one or more Source or object code written in any combination of programming languages, including object-oriented programming languages such as Smalltalk, C++ or the like, and programming languages such as "C" or similar programming languages The language is known as a programming language. Computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer. Execute on the terminal computer or server. In the latter case, the remote computer can be connected to the user computer via any type of network, including a local area network (LAN) or wide area network (WAN), or can be connected (for example, by using an Internet service provider Internet) to an external computer. In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) can be personalized by utilizing state information of computer-readable program instructions Electronic circuits execute computer readable program instructions to implement aspects of the present invention.

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 should be understood that each block in the flowchart illustrations and/or block diagrams and combinations of blocks in the flowchart illustrations and/or block diagrams can be implemented by computer readable program instructions.

These computer-readable program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment to generate a machine, so that instructions executed by the processor of the computer or other programmable data processing equipment can create means for implementing the functions/actions specified in one or more flowcharts and/or block diagram blocks. Such computer-readable program instructions may also be stored in a computer-readable storage medium, which instructions can instruct computers, programmable data processing equipment and/or other devices to function in specific ways, so that the computer on which the instructions are stored The readable storage medium includes an article of manufacture including instructions for implementing aspects of the functions/actions specified in the one or more flowcharts and/or block diagram blocks.

Computer-readable program instructions can also be loaded into a computer, other programmable data processing equipment, or other device, so that a series of operation steps can be executed on the computer, other programmable equipment, or other device to generate a computer-implemented processing program , so that the instructions executed on the computer, other programmable equipment or other devices implement the functions/actions specified in one or more flowcharts and/or block diagram blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, section, or instruction portion that includes one or more executable instructions for implementing specified logical functions. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in sequence may, in fact, be executed substantially concurrently, depending on the functionality involved, or The blocks can sometimes be executed in reverse order. It will also be noted that the blocks and block diagrams and/or flowchart illustrations described in the block diagrams and/or flowchart illustrations may be implemented by special purpose hardware-based systems that perform the specified functions or actions or implement combinations of special hardware and computer instructions The combination of blocks in it.

While the invention has been particularly shown and described with reference to one or more preferred embodiments, those skilled in the art will appreciate that other applications may be made in the invention without departing from the spirit and scope of the appended claims. various changes in form and detail. For example, although examples of addresses and address fields of particular lengths have been discussed, those skilled in the art will appreciate that the inventions described herein are not limited to the exemplary addresses and address field lengths. Additionally, it is worth noting that the described invention can be used in both virtualized and non-virtualized environments. For example, in various embodiments or use cases, a requestor may be assigned to a VM, a hypervisor, or a bare metal OS. For example, although the aspects have been described with respect to data processing hardware directing certain functions, it should be understood that the present invention may alternatively be implemented as a program product including a storage device that stores data that can be processed by a processor for execution. These functions or the code that causes these functions to be performed. As used herein, "storage device" is specifically defined to include legal articles only and exclude the signal medium itself, the transitory propagated signal itself, and the energy itself.

The above-described drawings and written descriptions of specific structures and functions are not presented to limit the scope of what the applicant has invented or the scope of the appended claims. Rather, the drawings and written description are provided to teach any person skilled in the art to make and use the invention for which patent protection is sought. Those skilled in the art will appreciate that not all features of a commercial embodiment of the invention are described or shown in the interest of clarity and understanding. 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 ultimate goals for the commercial embodiment. Such implementation-specific decisions may include, and may not be limited to, compliance with system-related, enterprise-related, government-related and other Varies with facility, location, and time. While a developer's effort might be complex and time-consuming in an absolute sense, such an effort would be a routine undertaking for those skilled in the art having the benefit of this disclosure. It must be understood that the invention disclosed and taught herein is susceptible to numerous and various modifications and alternative forms. Finally, use of a singular term such as, but not limited to, "a" is not intended to limit the number of items.

400: block

402: block

404: block

406: block

408: block

410: block

412: block

414: block

416: block

Claims (23)

A method of data processing in a data processing system comprising a processor, the method comprising: the processor receiving a first request including a virtual address from a requester; based on the first request, the processor determining a real address corresponding to the virtual address, encrypting at least a portion of the real address to obtain a cryptographically secure real address, and returning the cryptographically secure real address to the requester, wherein the encrypted comprising: the processor maintaining a key generation field specifying a current key generation of a plurality of different key generations, the maintaining including repeating over time through the plurality of different key generations looping through the key generation field; based on the current key generation specified by the key generation field, the processor selects one of a plurality of different keys for the encryption; the processor advances the key generation field to specify a new key generation after the current key generation based on remapping of a virtual address space containing the virtual address; upon receipt of a second request specifying a request address , the processor decrypts the request address to verify the request address as the cryptographically secure true address; and based on verifying the request address as the cryptographically secure true address, the processor allows Access to a resource of the data processing system identified by an address. The method of claim 1, wherein the receiving a first request comprises receiving a Peripheral Component Interconnect Express Service (PCIe ATS) protocol request. The method of claim 1, wherein encrypting at least a portion of the real address comprises encrypting the at least a portion of the real address using Advanced Encryption Standard (AES)-based encryption. The method of claim 1, wherein encrypting at least a portion of the real address comprises generating a hash of the at least a portion of the real address. The method of claim 1, wherein encrypting at least a portion of the real address includes refraining from encrypting lower order bits of the real address specifying an address within a memory page. The method of claim 1, further comprising combining additional data with the at least a portion of the real address before the encrypting. The method of claim 6, wherein the additional data includes at least bits from a processing address space identifier of the requester. The method according to claim 6, wherein the additional data includes a read-only field indicating whether the requester's access to the real address is read-only. A data processing system comprising: a processor configured to perform: receiving a first request from a requester including a virtual address; based on the first request, determining one of the virtual addresses corresponding to the virtual address real address, encrypt the at least a portion of the real address to obtain a cryptographically secure real address, and to pass the cryptographically secure real address back to the requester, wherein the encryption includes: the processor maintaining a key generation field, the key The key generation field specifies a current key generation of a plurality of different key generation, the maintenance includes repeatedly cycling the key generation field through the plurality of different key generation over time; based on the key generation by the key generation field specifies the current key generation, the processor selects one of a plurality of different keys to use for the encryption; the processor advances the key generation field based on a virtual address including the virtual address Space remapping to specify a new key generation after the current key generation; upon receiving a second request specifying a request address, decrypting the request address to verify the request address as the cryptographically secure a real address; and allowing access to a resource of the data processing system identified by the real address based on verifying the requested address as the cryptographically secure real address. The data processing system of claim 9, wherein the receiving a first request includes receiving a Peripheral Component Interconnect Express Address Translation Service (PCIe ATS) protocol request. The data processing system of claim 9, wherein encrypting at least a portion of the real address comprises encrypting the at least a portion of the real address using Advanced Encryption Standard (AES)-based encryption. The data processing system of claim 9, wherein encrypting at least a portion of the real address comprises generating a hash of the at least a portion of the real address. The data processing system of claim 9, wherein encrypting at least a portion of the real address includes avoiding encrypting lower order bits of the real address used to designate an address within a memory page. The data processing system of claim 9, wherein the processor is further configured to perform: combining additional data with the at least a portion of the real address before the encryption. The data processing system of claim 14, wherein the additional data includes at least bits from a processing address space identifier of the requester. The data processing system according to claim 14, wherein the additional data includes a read-only field indicating whether the requester's access to the real address is read-only. The data processing system according to claim 9, further comprising: a system memory coupled to the processor; and the requester coupled to the processor via a bus. A program product comprising: a storage device; and program code stored in the storage device, wherein the program code, when executed by a processor, causes the processor to execute: receiving from a requester a message containing a virtual address A first request; based on the first request, determine a real address corresponding to the virtual address, encrypt the at least a portion of the real address to obtain a cryptographically secure real address, and to pass the cryptographically secure real address back to the requester, wherein the encryption includes: the processor maintaining a key generation field, the key The key generation field specifies a current key generation of a plurality of different key generation, the maintenance includes repeatedly cycling the key generation field through the plurality of different key generation over time; based on the key generation by the key generation field specifies the current key generation, the processor selects one of a plurality of different keys to use for the encryption; the processor advances the key generation field based on a virtual address including the virtual address Space remapping to specify a new key generation after the current key generation; upon receiving a second request specifying a request address, decrypting the request address to verify the request address as the cryptographically secure a real address; and allowing access to a resource of the data processing system identified by the real address based on verifying the requested address as the cryptographically secure real address. The program product of claim 18, wherein the receiving a first request includes receiving a Peripheral Component Interconnect Express Address Translation Service (PCIe ATS) protocol request. The program product of claim 18, wherein encrypting at least a portion of the real address comprises encrypting the at least a portion of the real address using Advanced Encryption Standard (AES)-based encryption. The program product of claim 18, wherein encrypting at least a portion of the real address comprises generating a hash of the at least a portion of the real address. The program product of claim 18, wherein encrypting at least a portion of the real address includes avoiding encrypting lower order bits of the real address specifying an address within a memory page. The program product of claim 18, wherein the program code, when executed, causes the processor to: combine additional data with the at least a portion of the real address before the encryption.

Images