IP Library Granted Patent US 12,393,523
Granted Patent B2
US 12,393,523 · App. 17/709,867 · Granted Aug 19, 2025

Circuitry and methods for implementing micro-context based trust domains

Inventor: David M. Durham (Beaverton, OR)
Assignee: Intel Corporation
G06F12/1441G06F9/45558G06F12/0882G06F12/145G06F12/1458G06F2009/45583G06F2009/45587G06F2212/7201
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,393,523
App. No.
17/709,867
Granted
Aug 19, 2025
Kind
B2
Abstract

Systems, methods, and apparatuses for implementing micro-context based trust domains are described. In one example, a system includes a hardware processor core to implement a trust domain manager to manage one or more hardware isolated virtual machines as a respective trust domain with a region of protected memory, and assign a micro-context identification value, that is not readable by privileged system code that is to execute on the hardware processor core, to each granule of a plurality of granules of physical memory of the protected memory (e.g., where a granule is a proper subset of a page of memory relating to a single object in memory); and a memory management circuit coupled between the hardware processor core and the physical memory, wherein the memory management circuit is to prevent data in the protected memory having a first micro-context identification value from being accessed by code based on the code having a different micro-context identification value.

Claims (36)

1. An apparatus comprising:

a hardware processor core to implement a trust domain manager to manage one or more hardware isolated virtual machines as a respective trust domain with a region of protected memory, and assign a micro-context identification value, that is not readable by privileged system code that is to execute on the hardware processor core, to each granule of a plurality of granules of physical memory of the protected memory; and

a memory management circuit coupled between the hardware processor core and the physical memory, wherein the memory management circuit is to prevent data in the protected memory having a first micro-context identification value from being accessed by code based on the code having a different micro-context identification value.

2. The apparatus of claim 1 , wherein the trust domain manager is to store each micro-context identification value in a data structure that includes a virtual address to physical address mapping for each granule of the plurality of granules of the physical memory of the protected memory.

3. The apparatus of claim 2 , wherein the memory management circuit is to prevent data in the protected memory having a first virtual address from being accessed by code having a different virtual address in its virtual address to physical address mapping in the data structure.

4. The apparatus of claim 2 , wherein the physical memory comprises a plurality of pages, and the data structure comprises a micro-context identification value for each granule of the plurality of granules of each page of the physical memory and a virtual address to physical address mapping for each page.

5. The apparatus of claim 1 , wherein the granule is less than a page of the physical memory.

6. The apparatus of claim 1 , wherein the privileged system code includes an operating system and a virtual machine monitor of the one or more hardware isolated virtual machines that are to execute on the hardware processor core.

7. The apparatus of claim 1 , wherein, in response to a request from the privileged system code to provide a function to a trust domain to execute, the trust domain manager is to store the function in the protected memory, and assign each granule of memory utilized to store the function a same micro-context identification value.

8. The apparatus of claim 1 , wherein, in response to a request from the privileged system code to store data into the protected memory, the trust domain manager is to overwrite any assigned micro-context identification values with a micro-context identification value for code that is currently executing.

9. A method comprising:

managing one or more hardware isolated virtual machines as a respective trust domain with a region of protected memory by a trust domain manager of a hardware processor core;

assigning a micro-context identification value, that is not readable by privileged system code that is executing on the hardware processor core, to each granule of a plurality of granules of physical memory of the protected memory by the trust domain manager of the hardware processor core;

allowing, by a memory management circuit coupled between the hardware processor core and the physical memory, a first memory access of data in the protected memory having a first micro-context identification value requested by a first code based on the first code having the first micro-context identification value; and

preventing, by the memory management circuit, a second memory access of the data in the protected memory having the first micro-context identification value requested by a second code based on the second code having a different micro-context identification value.

10. The method of claim 9 , further comprising storing, by the trust domain manager, each micro-context identification value in a data structure that includes a virtual address to physical address mapping for each granule of the plurality of granules of the physical memory of the protected memory.

11. The method of claim 10 , further comprising preventing, by the memory management circuit, data in the protected memory having a first virtual address from being accessed by code having a different virtual address in its virtual address to physical address mapping in the data structure.

12. The method of claim 10 , wherein the physical memory comprises a plurality of pages, and the data structure comprises a micro-context identification value for each granule of the plurality of granules of each page of the physical memory and a virtual address to physical address mapping for each page.

13. The method of claim 9 , wherein the granule is less than a page of the physical memory.

14. The method of claim 9 , wherein the privileged system code includes an operating system and a virtual machine monitor of the one or more hardware isolated virtual machines that are executing on the hardware processor core.

15. The method of claim 9 , further comprising, in response to a request from the privileged system code to provide a function to a trust domain to execute:

storing the function in the protected memory, and

assigning each granule of memory utilized to store the function a same micro-context identification value by the trust domain manager.

16. The method of claim 9 , further comprising, in response to a request from the privileged system code to store data into the protected memory:

overwriting, by the trust domain manager, any assigned micro-context identification values with a micro-context identification value for code that is currently executing.

17. An apparatus comprising:

a physical memory;

a hardware processor core to implement a trust domain manager to manage one or more hardware isolated virtual machines as a respective trust domain with a region of protected memory, and assign a micro-context identification value, that is not readable by privileged system code that is to execute on the hardware processor core, to each granule of a plurality of granules of the physical memory of the protected memory; and

a memory management circuit coupled between the hardware processor core and the physical memory, wherein the memory management circuit is to prevent data in the protected memory having a first micro-context identification value from being accessed by code based on the code having a different micro-context identification value.

18. The apparatus of claim 17 , wherein the trust domain manager is to store each micro-context identification value in a data structure that includes a virtual address to physical address mapping for each granule of the plurality of granules of the physical memory of the protected memory.

19. The apparatus of claim 18 , wherein the memory management circuit is to prevent data in the protected memory having a first virtual address from being accessed by code having a different virtual address in its virtual address to physical address mapping in the data structure.

20. The apparatus of claim 18 , wherein the physical memory comprises a plurality of pages, and the data structure comprises a micro-context identification value for each granule of the plurality of granules of each page of the physical memory and a virtual address to physical address mapping for each page.

21. The apparatus of claim 17 , wherein the granule is less than a page of the physical memory.

22. The apparatus of claim 17 , wherein the privileged system code includes an operating system and a virtual machine monitor of the one or more hardware isolated virtual machines that are to execute on the hardware processor core.

23. The apparatus of claim 17 , wherein, in response to a request from the privileged system code to provide a function to a trust domain to execute, the trust domain manager is to store the function in the protected memory, and assign each granule of memory utilized to store the function a same micro-context identification value.

24. The apparatus of claim 17 , wherein, in response to a request from the privileged system code to store data into the protected memory, the trust domain manager is to overwrite any assigned micro-context identification values with a micro-context identification value for code that is currently executing.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Apr 7, 2022
From: DURHAM, DAVID M.
To: INTEL CORPORATION
Reel/Frame 059537/0625 →
Continuity (1)
Related Publication 20230315648A1 · Oct 5, 2023
References Cited (127)
US 3916385A · Parmar et al. · 1975 [cited by applicant]
US 4809160A · Mahon et al. · 1989 [cited by applicant]
US 4821169A · Sites et al. · 1989 [cited by applicant]
US 5809564A · Craze et al. · 1998 [cited by applicant]
US 6009503A · Liedtke · 1999 [cited by applicant]
US 6048940A · Blaedel et al. · 2000 [cited by applicant]
US 6671699B1 · Black et al. · 2003 [cited by applicant]
US 6694450B1 · Kidder et al. · 2004 [cited by applicant]
US 6823433B1 · Barnes et al. · 2004 [cited by applicant]
US 7401234B2 · Case et al. · 2008 [cited by applicant]
US 7761674B2 · Durham et al. · 2010 [cited by applicant]
US 8554984B2 · Yano et al. · 2013 [cited by applicant]
US 8595442B1 · James-Roxby et al. · 2013 [cited by applicant]
US 9026866B2 · Balasubramanian · 2015 [cited by applicant]
US 9390031B2 · Durham et al. · 2016 [cited by applicant]
US 9436847B2 · Durham et al. · 2016 [cited by applicant]
US 9652375B2 · Stark et al. · 2017 [cited by applicant]
US 9697142B2 · Koeberl et al. · 2017 [cited by applicant]
US 10162694B2 · Stark et al. · 2018 [cited by applicant]
US 10496573B2 · Schulz et al. · 2019 [cited by applicant]
US 10565132B2 · Schulz et al. · 2020 [cited by applicant]
US 10671547B2 · Koeberl et al. · 2020 [cited by applicant]
US 20040031030A1 · Kidder et al. · 2004 [cited by applicant]
US 20040158775A1 · Shibuya et al. · 2004 [cited by applicant]
US 20050193217A1 · Case et al. · 2005 [cited by applicant]
US 20060187941A1 · Andersen · 2006 [cited by applicant]
US 20060256877A1 · Szczepanek et al. · 2006 [cited by applicant]
US 20060256878A1 · Szczepanek et al. · 2006 [cited by applicant]
US 20070055837A1 · Rajagopal et al. · 2007 [cited by applicant]
US 20070156999A1 · Durham · 2007 [cited by examiner]
US 20080209282A1 · Lee et al. · 2008 [cited by applicant]
US 20080244725A1 · Dewan · 2008 [cited by examiner]
US 20090172343A1 · Savagaonkar · 2009 [cited by examiner]
US 20090271536A1 · Tiennot · 2009 [cited by applicant]
US 20090292977A1 · Bradley et al. · 2009 [cited by applicant]
US 20090327648A1 · Savagaonkar · 2009 [cited by examiner]
US 20100162038A1 · Hulbert et al. · 2010 [cited by applicant]
US 20130227704A1 · Boivie · 2013 [cited by examiner]
US 20130232238A1 · Cohn · 2013 [cited by examiner]
US 20130318322A1 · Shetty et al. · 2013 [cited by applicant]
US 20130326288A1 · Datta et al. · 2013 [cited by applicant]
US 20140115283A1 · Radovic et al. · 2014 [cited by applicant]
US 20140281354A1 · Tkacik et al. · 2014 [cited by applicant]
US 20140372698A1 · Lee et al. · 2014 [cited by applicant]
US 20160048378A1 · Varma · 2016 [cited by applicant]
US 20160124802A1 · Gabor et al. · 2016 [cited by applicant]
US 20160259682A1 · Stark et al. · 2016 [cited by applicant]
US 20160283300A1 · Stark et al. · 2016 [cited by applicant]
US 20160371139A1 · Stark et al. · 2016 [cited by applicant]
US 20170177429A1 · Stark et al. · 2017 [cited by applicant]
US 20180060250A1 · Hildesheim et al. · 2018 [cited by applicant]
US 20180074715A1 · Farmahini-Farahani et al. · 2018 [cited by applicant]
US 20190138755A1 · Kida · 2019 [cited by examiner]
US 20200004953A1 · Lemay et al. · 2020 [cited by applicant]
US 20210006395A1 · Durham · 2021 [cited by examiner]
US 20210200546A1 · Lemay et al. · 2021 [cited by applicant]
EP 0428079A2 · 1991 [cited by applicant]
JP 03244054A · 1991 [cited by applicant]
WO 2007079011A3 · 2007 [cited by applicant]
“Intel(R) Trusted Execution Technology: Hardware-based Technology for Enhancing Server Platform Security”, White Paper, 2012, 8 pages. [cited by applicant]
Advisory Action from U.S. Appl. No. 11/323,446, Apr. 17, 2012, 3 pages. [cited by applicant]
Angelo-Oracle. “SPARC M7 Chip—32 cores”, Oracle.com, Aug. 15, 2014. Web. Accessed Dec. 21, 2015. 8 pages. URL: <http://blogs.oracle.com/rajadurai/entry/sparc_m7_chip_32_cores>. [cited by applicant]
Arm, “Arm® Architecture Reference Manual Supplement Morello for A-profile Architecture”, Document No. DDI0606, Document Version: A.j, 2019-2021, 1288 pages. [cited by applicant]
Biin: “CPA Architecture Reference Manual”, 1988, 401 pages. [cited by applicant]
Burow et al., “CUP: Comprehensive User-Space Protection for C/C++”, Session 9: Software Security, ASIACCS'18, Jun. 4-8, 2018, pp. 381-392. [cited by applicant]
Carr et al., “DataShield: Configurable Data Confidentiality and Integrity”, Asia CCS '17, Apr. 2-6, 2017, pp. 193-204. [cited by applicant]
Chen et al., “Shreds: Fine-grained Execution Units with Private Memory”, IEEE Symposium on Security and Privacy, 2016, pp. 56-71. [cited by applicant]
CHERI, “Capability Hardware Enhanced RISC Instructions (CHERI)”, available online at <https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/>, 2010-2019, 2 pages. [cited by applicant]
Dartmouth, “ELFbac: Runtime Intent-Level ABI-Granular Memory Protection for Linux”, available online at <https://www.cs.dartmouth.edu/˜sergey/io/elfbac/>, retrieved on May 1, 2020, 1 page. [cited by applicant]
Duarte, “Memory Translation and Segmentation” Aug. 2008, p. 1-7. [cited by applicant]
Duck et al., “EffectiveSan: Type and Memory Error Detection using Dynamically Typed C/C++”, PLDI'18, Jun. 18-22, 2018, pp. 181-195. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Dec. 30, 2011, 18 pages. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Jan. 17, 2013, 17 pages. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Jul. 16, 2015, 17 pages. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Jul. 28, 2014, 16 pages. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Jul. 7, 2009, 21 pages. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Oct. 15, 2010, 17 pages. [cited by applicant]
Final Office Action from U.S. Appl. No. 11/323,446, Sep. 20, 2013, 14 pages. [cited by applicant]
Gil et al., “There's a Hole in the Bottom of the C: On the Effectiveness of Allocation Protection”, IEEE Cybersecurity Development (SecDev), Sep. 30-Oct. 2, 2018, 8 pages. [cited by applicant]
Gove, D., et al., “Detecting memory access errors,” Nov. 25, 2015, 17 pages. [cited by applicant]
Gretton-Dann et al., “Arm A-Profile Architecture Developments 2018: Armv8.5-A”, available online at <https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-2018-… [cited by applicant]
https://courses.cs.washington.edu/courses/cse351/17wi/lectures/CSE351-L02-memory-L17wi.pdfAuthor: Ceze; Title: CSE351:Memory, Data, & Addressing I, Date: Winter, 2017 (Year: 2017). [cited by applicant]
Intel, “Intel 64 and IA-32 Architectures Software Developer's Manual”, vol. 3A, System Programming Guide, Part 1, Order No. 253668-060US, Sep. 2016, 468 pages. [cited by applicant]
International Preliminary Report on Patentability for Application No. PCT/US2006/048940, Jul. 1, 2008, 8 pages. [cited by applicant]
International Search Report and Written Opinion for Application No. PCT/US2006/048940, Sep. 25, 2007, 15 pages. [cited by applicant]
International Search Report and Written Opinion for Application No. PCT/US2016/063211, Mar. 7, 2017, 11 pages. [cited by applicant]
Introduction to SPARC M7 and Silicon Secured Memory (SSM), Retrieved from https://swisdev.oracle.com/_files/What-Is-SSM.html on Jul. 4, 2016, 2 pages. [cited by applicant]
Jeon et a., “HexType: Efficient Detection of Type Confusion Errors for C++”, CCS '17, Session K3: Program Analysis, Oct. 2017, pp. 2373-2387. [cited by applicant]
Kwon et al., “Low-Fat Pointers: Compact Encoding and Efficient Gate-Level Implementation of Fat Pointers for Spatial Safety and Capability-based Security”, Proceedings of the 2013 ACM SIGSAC Conference on Computer & Com… [cited by applicant]
Lemay et al., “Cryptographic Capability Computing”, Micro'21, pp. 253-267 (2021). [cited by applicant]
Liljestrand et al., “PAC it up: Towards Pointer Integrity using ARM Pointer Authentication”, Cornell University, Nov. 22, 2018, 21 pages. [cited by applicant]
LogMeIn Support, “What is Privilege Separation in SSH?”, available online at <https://web.archive.org/web/20191218064501/https://help.logmein.com/articles/en_US/FAQ/What-is-Privilege-Separation-in-SSH-en1>, Dec. 18, 201… [cited by applicant]
M. Rutland, “ARMv8.3 Pointer Authentication”,, Linux Security Summit, Sep. 14, 2017, 24 slides. [cited by applicant]
Mahon M.J., et al., “Hewlett-Packard Precision Architecture: The Processor,” Hewlett-Packard Journal, Aug. 1986, 19 pages. [cited by applicant]
McIlroy et al., “Spectre is Here to Stay: An Analysis of Side-Channels and Speculative Execution”, Cornell University, Feb. 15, 2019, pp. 1-26. [cited by applicant]
Menon et al., “Shakti-T: A RISC-V Processor with Light Weight Security Extensions”, Conference: the Hardware and Architectural Support for Security and Privacy, Jun. 25, 2017, 9 pages. [cited by applicant]
Miller, Matt, “Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape”, Microsoft Security Response Center (MSRC), Feb. 7, 2019, 32 pages. [cited by applicant]
Min R., et al., “Improving Performance of Large Physically Indexed Caches by Decoupling Memory Addresses From Cache Addresses,” IEEE Transactions on Computers, vol. 50, No. 11, Nov. 2001, pp. 1191-1201. [cited by applicant]
Nagarakatte et al., “CETS: Compiler-Enforced Temporal Safety for C”, ISMM'10, Jun. 5-6, 2010, pp. 31-40. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Apr. 23, 2010, 16 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Jan. 15, 2015, 18 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Jun. 22, 2012, 16 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Jun. 7, 2013, 18 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Mar. 15, 2011, 16 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Mar. 20, 2014, 15 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Nov. 5, 2015, 5 pages. [cited by applicant]
Non-Final Office Action from U.S. Appl. No. 11/323,446, Oct. 7, 2008, 17 pages. [cited by applicant]
Non-Final Office Action, U.S. Appl. No. 16/729,358, Sep. 16, 2020, 17 pages. [cited by applicant]
Notice of Allowance from U.S. Appl. No. 11/323,446, Mar. 14, 2016, 5 pages. [cited by applicant]
Notice of Allowance, U.S. Appl. No. 16/729,358, Jul. 6, 2021, 8 pages. [cited by applicant]
Qualcomm, “Pointer Authentication on ARMv8.3: Design and Analysis of the New Software Security Instructions”, Jan. 2017, 12 pages. [cited by applicant]
Serebryany et al., “AddressSanitizer: A Fast Address Sanity Checker”, 2012 Usenix Annual Technical Conference, Jun. 13-15, 2012, 10 pages. [cited by applicant]
Serebryany et al., “Memory Tagging And How It Improves C/C++ Memory Safety”, Feb. 2018, 14 pages. [cited by applicant]
Serebryany et al., “Memory Tagging: How It Improves C/C++ Memory Safety” Google, LLVM Developers' Meeting, Oct. 2018, 29 slides. [cited by applicant]
Serebryany, Kostya, “Security: ARM Memory Tagging Extension and How It Improves C/C++ Memory Safety”, vol. 44, No. 2, Summer 2019, pp. 12-16. [cited by applicant]
Suh et al., “Secure Program Execution via Dynamic Information Flow Tracking”, ASPLOS'04, Oct. 9-13, 2004, pp. 85-96. [cited by applicant]
T. Nyman et al., “HardScope: Thwarting DOP attacks with Hardware-Assisted Run-time Scope Enforcement”, May 2017, pp. 1-20. [cited by applicant]
The Chromium Projects, “Multi-Process Architecture”, available online at <https://web.archive.org/web/20191030200549/https://www.chromium.org/developers/design-documents/multi-process-architecture>, Oct. 30, 2019, 2 pag… [cited by applicant]
Tsampas et al., “Towards Automatic Compartmentalization of C Programs on Capability Machines”, In Proceedings of the International Conference on Foundations of Computer Science, 2017, 14 pages. [cited by applicant]
Vasilakis et al., “BreakApp: Automated, Flexible Application Compartmentalization”, Network and Distributed Systems Security (NDSS) Symposium, Feb. 18-21, 2018, 15 pages. [cited by applicant]
Watson et al., “An Introduction to CHERI”, University of Cambridge, Computer Laboratory, Technical Report, No. 941, Sep. 2019, 43 pages. [cited by applicant]
Watson et al., “Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 8)”, University of Cambridge, Computer Laboratory, Technical Report, No. 951, Oct. 2020, 590 pages. [cited by applicant]
Watson et al., “CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization”, IEEE Symposium on Security and Privacy, 2015, pp. 20-37. [cited by applicant]
Watson, “Capsicum: Practical capabilities for UNIX”, USENIX Security, 2010, 17 pages. [cited by applicant]
Wesley et al., “Cornucopia: Temporal Safety for CHERI Heaps”, . In Proceedings of the 41st IEEE Symposium on Security and Privacy, 2020, pp. 1507-1524. [cited by applicant]
Wilkes J., et al., “A Comparison of Protection Lookaside Buffers and the PA-RISC Protection Architecture,” Mar. 1992, Hewlett-Packard, 12 pages. [cited by applicant]
Xia et al., “CHERIvoke: Characterising Pointer Revocation using CHERI Capabilities for Temporal Memory Safety”, MICRO '52, Oct. 2019, pp. 545-557. [cited by applicant]