JP-2024535180-A5 -

Dates

Publication Date

20260508

Application Date

20220927

Description

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 generation field that identifies which of several keys was used to encrypt the real address. 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. This is a high-level logic flowchart of an exemplary process in which a processor implements key generations , according to one embodiment. 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 (here including only the upper bit field 502) truncated to a desired number of bits, which includes a host field (HF) 506. For example, in the example shown, the host field 506 may be selected to be 12 bits long, such that the intermediate RA has a total length of 43 bits. In other embodiments, 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 a concatenation of the relevant RID and PASID. Figure 6 further shows that the processor 102 may optionally include a Read-Only (RO) field 602 in 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, in 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 may optionally or additionally include a key generation field, as further discussed below with reference to Figures 8-9. Referring now to Figure 8, a partial diagram of the security logic 202 of Figure 2, according to one embodiment, is shown illustrating the portion that supports the use of key generations . In at least some embodiments, the security logic 202 is configured to transparently update the usage of cryptographic keys in the key store 208 to prevent a malicious or compromised requester from successfully reusing an old sRA. In the embodiment of Figure 8, the security logic 202 preferably implements a Generation (G) field 800 associated with the cryptographic key assigned to each supported requester. The Generation field 800 identifies which generation of the cryptographic key is being used. For example, assuming that only two cryptographic key generations (e.g., represented as key generations A and B) are supported, the key store 208 may include Key1 and Key2 for each supported requester, respectively, for key generations A and B. Thus, the key store 208 includes Key1A and Key2A, which are keys for use in key generation A, and Key1B and Key2B, which are keys for use in key generation B, for a given requester. This array means that at some point, the generation field 800 will have a value of b'0', for example, representing key generation 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 sRA 520. At a different point in time, the generation field 800 will have a value of b'1', for example, representing key generation B. Based on the fact that the generation field 800 indicates key generation 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 sRA 520. In either case, the value of the generation field 800 is placed in the generation field 804 that is added to the encrypted output by the encryption engine 204 to obtain the encryption field 522 of sRA 520. It should be noted that in the shown embodiment, the encryption engine 204