IP Library › Granted Patent US 12,353,902
Granted Patent B2
US 12,353,902 · App. 17/716,823 · Granted Jul 8, 2025

Confidential compute architecture integrated with direct swap caching

Inventors: Ishwar Agarwal (Redmond, WA); Bryan David Kelly (Carnation, WA); Vishal Soni (Redmond, WA)
Assignee: Microsoft Technology Licensing, LLC
G06F9/45558G06F2009/4557G06F2009/45579G06F2009/45583
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,353,902
App. No.
17/716,823
Granted
Jul 8, 2025
Kind
B2
Abstract

Systems and methods for a confidential compute architecture integrated with direct swap caching are described. An example method for managing a near memory and a far memory includes, in response to determining that the far memory contains an encrypted version of a first block of data, retrieving from the far memory the encrypted version of the first block of data, decrypting the first block of data using a first key for exclusive use by a first virtual machine associated with the system, and providing a decrypted version of the first block of data to the requestor. The method further includes swapping out a second block of data having an address conflict with the first block of data from the near memory to the far memory, where the second block of data is encrypted using a second key for exclusive use by a second virtual machine associated with the system.

Claims (30)

1. A method for managing a system having a near memory and a far memory, the method comprising:

receiving a read request from a requestor to read a first block of data that is either stored in the near memory or in the far memory, wherein the read request includes a first key associated with a first virtual machine corresponding to the system, wherein the first key is for exclusive use by the first virtual machine;

in response to determining that the far memory contains an encrypted version of the first block of data: (1) retrieving from the far memory the encrypted version of the first block of data, decrypting the first block of data using the first key, and providing a decrypted version of the first block of data to the requestor, and (2) swapping out a second block of data having an address conflict with the first block of data from the near memory to the far memory, wherein the second block of data is encrypted using a second key associated with a second virtual machine corresponding to the system, and wherein the second key is for exclusive use by the second virtual machine; and

analyzing a metadata portion associated with the first block of data, the metadata portion including: (1) first information related to whether the near memory contains the first block of data or whether the far memory contains the first block of data, (2) second information comprising a first trusted domain identifier value associated with the second block of data stored in the near memory, and (3) third information comprising a second trusted domain identifier value associated with the first block of data stored in the far memory, wherein each of the first trusted domain identifier value and the second trusted domain identifier value is managed by a near memory controller associated with the near memory regardless of whether the first block of data is stored in the near memory or the far memory.

2. The method of claim 1 , wherein determining that the far memory contains an encrypted version of the first block of data comprises analyzing the first information included in the metadata portion associated with the first block of data.

3. The method of claim 1 , wherein the far memory is associated with a far memory system having a root port and an endpoint separated by at least one physical link, and wherein a transaction over the at least one physical link corresponding to the read request is encrypted resulting in a double encryption of the first block of data during transit over the at least one physical link.

4. The method of claim 1 , wherein the far memory is associated with a far memory system having a root port and an endpoint separated by at least one physical link, and wherein the method further comprises performing an integrity check for a set of transactions between the root port and the endpoint over the at least one physical link.

5. The method of claim 1 , wherein neither the first trusted domain identifier value nor the second trusted domain identifier value is transmitted to the far memory.

6. The method of claim 1 , wherein the second information comprises a same trusted domain identifier value associated with the second block of data regardless of whether the second block of data is stored in the near memory or the far memory.

7. The method of claim 1 , wherein each of the first block of data and the second block of data comprises a cache line for a central processing unit (CPU) associated with the system.

8. A system having a near memory and a far memory, the system comprising:

a near memory controller configured to receive a read request from a requestor to read a first block of data that is either stored in the near memory or in the far memory, wherein the read request includes a first key associated with a first virtual machine corresponding to the system, wherein the first key is for exclusive use by the first virtual machine;

the near memory controller further configured to in response to determining that the far memory contains an encrypted version of the first block of data: (1) retrieve from the far memory the encrypted version of the first block of data, decrypting the first block of data using the first key, and provide a decrypted version of the first block of data to the requestor, and (2) swap out a second block of data having an address conflict with the first block of data from the near memory to the far memory, wherein the second block of data is encrypted using a second key associated with a second virtual machine corresponding to the system, and wherein the second key is for exclusive use by the second virtual machine; and

wherein the near memory controller is further configured to analyze a metadata portion associated with the first block of data, the metadata portion having: (1) first information related to whether the near memory contains the first block of data or whether the far memory contains the first block of data, (2) second information comprising a first trusted domain identifier value associated with the second block of data stored in the near memory and (3) third information comprising a second trusted domain identifier value associated with the first block of data stored in the far memory, and wherein each of the first trusted domain identifier value and the second trusted domain identifier value is managed by the near memory controller regardless of whether the first block of data is stored in the near memory or the far memory.

9. The system of claim 8 , wherein as part of determining that the far memory contains an encrypted version of the first block of data, the near memory controller is further configured to analyze the first information included in the metadata portion associated with the first block of data.

10. The system of claim 8 , wherein the far memory is associated with a far memory system having a root port and an endpoint separated by at least one physical link, and wherein a transaction over the at least one physical link corresponding to the read request is encrypted by the far memory system, resulting in a double encryption of the first block of data during transit over the at least one physical link.

11. The system of claim 8 , wherein the far memory is associated with a far memory system having a root port and an endpoint separated by at least one physical link, and wherein, using a message authentication code, an integrity check is performed for any transactions over the at least one physical link.

12. The system of claim 8 , wherein neither the first trusted domain identifier value nor the second trusted domain identifier value is transmitted to the far memory.

13. The system of claim 8 , wherein the second information comprises a same trusted domain identifier value associated with the second block of data regardless of whether the second block of data is stored in the near memory or the far memory.

14. The system of claim 8 , wherein the system further comprises a central processing unit (CPU), and wherein each of the first block of data and the second block of data comprises a cache line for the CPU.

15. A method for managing a system having a near memory and a far memory, wherein the far memory is associated with a far memory system having a root port and an endpoint separated by at least one physical link, the method comprising:

performing an integrity check for a set of transactions between the root port and the endpoint over the at least one physical link;

receiving a read request from a requestor to read a first block of data that is either stored in the near memory or in the far memory, wherein the read request includes a first key associated with a first virtual machine corresponding to the system, and wherein the first key is for exclusive use by the first virtual machine; and

in response to determining that the far memory contains an encrypted version of the first block of data: (1) retrieving from the far memory the encrypted version of the first block of data, decrypting the first block of data using the first key, and providing a decrypted version of the first block of data to the requestor, wherein a latency associated with the decrypting is sufficient to allow for a completion of the integrity check and (2) swapping out a second block of data having an address conflict with the first block of data from the near memory to the far memory, wherein the second block of data is encrypted using a second key associated with a second virtual machine corresponding to the system, and wherein the second key is for exclusive use by the second virtual machine; and

analyzing a metadata portion associated with the first block of data, the metadata portion having: (1) first information related to whether the near memory contains the first block of data or whether the far memory contains the first block of data, (2) second information comprising a first trusted domain identifier value associated with the second block of data stored in the near memory, and (3) third information comprising a second trusted domain identifier value associated with the first block of data stored in the far memory, and wherein each of the first trusted domain identifier value and the second trusted domain identifier value is managed by a near memory controller associated with the near memory regardless of whether the first block of data is stored in the near memory or the far memory.

16. The method of claim 15 , wherein determining that the far memory contains an encrypted version of the first block of data comprises analyzing the first information included in the metadata portion associated with the first block of data.

17. The method of claim 15 , wherein the far memory is associated with a far memory system having a root port and an endpoint separated by at least one physical link, and wherein a transaction over the at least one physical link corresponding to the read request is encrypted by the far memory system, resulting in a double encryption of the first block of data during transit over the at least one physical link.

18. The method of claim 15 , wherein neither the first trusted domain identifier value nor the second trusted domain identifier value is transmitted to the far memory.

19. The method of claim 15 , wherein the second information comprises a same trusted domain identifier value associated with the second block of data regardless of whether the second block of data is stored in the near memory or the far memory.

20. The method of claim 15 , wherein each of the first block of data and the second block of data comprises a cache line for a central processing unit (CPU) associated with the system.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Apr 8, 2022
From: KELLY, BRYAN DAVID; AGARWAL, ISHWAR; SONI, VISHAL
To: MICROSOFT TECHNOLOGY LICENSING, LLC
Reel/Frame 059550/0232 →
Continuity (1)
Related Publication 20230325225A1 · Oct 12, 2023
References Cited (14)
US 7624240B1 · Colbert · 2009 [cited by examiner]
US 7925850B1 · Waldspurger · 2011 [cited by examiner]
US 9418220B1 · Mckee et al. · 2016 [cited by applicant]
US 20120166891A1 · Dahlen et al. · 2012 [cited by applicant]
US 20160239430A1 · Tsirkin et al. · 2016 [cited by applicant]
US 20170344298A1 · Shih · 2017 [cited by examiner]
US 20180285140A1 · Kaplan · 2018 [cited by examiner]
US 20180341768A1 · Marshall et al. · 2018 [cited by applicant]
US 20200371692A1 · Van Doorn et al. · 2020 [cited by applicant]
US 20200409740A1 · Li · 2020 [cited by examiner]
US 20220414001A1 · Agarwal et al. · 2022 [cited by applicant]
“International Search Report and Written Opinion Issued in PCT Application No. PCT/US23/011567”, Mailed Date: May 4, 2023, 13 Pages. [cited by applicant]
“Compute Express Link Specification”, In the White Paper of Compute Express Link, Revision 2.0, Oct. 26, 2020, 628 Pages. [cited by applicant]
“Trusted Execution Environment (TEE) 101: A Primer”, In White Paper of A Secure Technology Alliance Mobile Council, Jun. 2018, 24 Pages. [cited by applicant]