CN117494108B - 可信执行环境实现方法、计算机设备及存储介质 - Google Patents
可信执行环境实现方法、计算机设备及存储介质 Download PDFInfo
- Publication number
- CN117494108B CN117494108B CN202311850601.7A CN202311850601A CN117494108B CN 117494108 B CN117494108 B CN 117494108B CN 202311850601 A CN202311850601 A CN 202311850601A CN 117494108 B CN117494108 B CN 117494108B
- Authority
- CN
- China
- Prior art keywords
- execution environment
- memory
- trusted execution
- trusted
- enclave
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 45
- 230000015654 memory Effects 0.000 claims abstract description 321
- 238000002955 isolation Methods 0.000 claims abstract description 49
- 230000008569 process Effects 0.000 claims description 12
- 238000011084 recovery Methods 0.000 claims description 9
- 238000004590 computer program Methods 0.000 claims description 8
- 238000013507 mapping Methods 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 6
- 230000005856 abnormality Effects 0.000 claims description 4
- 238000010276 construction Methods 0.000 abstract description 4
- 238000012795 verification Methods 0.000 abstract description 4
- 238000013175 transesophageal echocardiography Methods 0.000 description 112
- 230000007246 mechanism Effects 0.000 description 27
- 208000006930 Pseudomyxoma Peritonei Diseases 0.000 description 14
- 229920000306 polymethylpentene Polymers 0.000 description 14
- 238000007726 management method Methods 0.000 description 13
- 238000005516 engineering process Methods 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 238000012550 audit Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000003068 static effect Effects 0.000 description 5
- 230000002829 reductive effect Effects 0.000 description 4
- 238000004088 simulation Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000013473 artificial intelligence Methods 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 230000006378 damage Effects 0.000 description 2
- 230000036961 partial effect Effects 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000008094 contradictory effect Effects 0.000 description 1
- 230000002950 deficient Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
- G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
本发明公开了一种可信执行环境实现方法、计算机设备及存储介质，本发明面向RISC‑V平台构建多种可信执行环境安全原语，包括可信执行环境CPU保护、可信执行环境内存隔离以及可信执行环境内存共享，以提供对多种TEE抽象的支持，包括机密虚拟机、S‑Enclave以及U‑Enclave，使用户可以根据机密任务的大小选择合适的TEE抽象。此外，本发明支持在机密虚拟机内部构建安全隔离域，并运行Enclave，能够防止未经安全验证的恶意虚拟机内核侵害和泄露用户应用中的敏感数据。安全监视器负责可信执行环境和富执行环境以及可信执行环境内部实例之间的内存隔离和共享。
Description
技术领域
本发明涉及机密计算技术领域，尤其涉及的是一种可信执行环境实现方法、计算机设备及存储介质。
背景技术
当前各大主流CPU厂商都推出基于其自家CPU硬件扩展的TEE架构，能够创建一个隔离的环境，为用户的代码和数据提高机密性和完整性保证。目前主流的可信执行环境（Trusted Execution Environment，TEE）架构可以分为两类，一类是面向虚拟化环境的机密虚拟机，另一类是面向普通进程的Enclave（飞地）。这些Enclave和机密虚拟机技术架构也逐渐应用于区块链、大数据、人工智能等领域，成为构建其他技术的安全基石。
目前的这些TEE架构在设计时仅提供单一的抽象，或者是机密虚拟机或者是Enclave。这种单一的抽象设计使其难以适应用户广泛的机密任务需求。且目前大部分TEE架构的构建都基于闭源的商业CPU硬件安全扩展，这导致其安全性难以审计。此外，机密虚拟机这种虚拟机（Virtual Machine，VM）级的隔离要比Enclave这种进程级的隔离粒度大的多。目前机密虚拟机大部分还是运行一些宏内核操作系统，比如Linux，这使得其内部通常包含一些安全性难以审计的第三方的软件、库和驱动等。虽然机密虚拟机能够防御来自其外部的特权软件的侵害，但其内部仍然面临与外部非虚拟化环境同样的安全问题，若机密虚拟机中未经安全验证的恶意虚拟机内核则可能会侵害和泄露用户应用中的敏感数据。
因此，现有技术还有待于改进和发展。
发明内容
鉴于上述现有技术的不足，本发明的目的在于提供一种可信执行环境实现方法、计算机设备及存储介质，以解决现有TEE架构单一抽象、安全性难以审计以及由于缺乏内部隔离从而可能导致的未经安全验证的恶意虚拟机内核侵害和泄露用户应用中的敏感数据的问题。
本发明的技术方案如下：
第一方面，本发明提供了一种可信执行环境实现方法，其包括：
安全监控器响应用户请求，创建可信执行环境实例；其中，所述可信执行环境实例包括机密虚拟机、管理态飞地与用户态飞地；
在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换与恢复，并进行安全检查；
安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享。
本发明进一步地设置，所述在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换与恢复，并进行安全检查的步骤包括：
在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查；
在可信执行环境退出至富执行环境时，安全监控器对可信执行环境中的敏感寄存器进行清空并对微架构信息进行清除。
本发明进一步地设置，所述在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查的步骤包括：
配置中断异常代理寄存器，当可信执行环境中发生中断和异常时，将可信执行环境自身可处理的中断和异常代理给可信执行环境，并对可信执行环境不可处理的中断和异常进行处理。
本发明进一步地设置，所述在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查的步骤还包括：
当发生异常导致可信执行环境退出并通过富执行环境处理后，在可信执行环境恢复运行时对CPU寄存器状态进行检查，并在可信执行环境退出时对敏感寄存器进行清空。
本发明进一步地设置，安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤包括：
当所述安全监控器注册完成一段连续物理内存作为可信内存区后，所述安全监控器申请一个位图对连续物理内存的状态进行记录，并根据位图对整个可信内存区的内存进行管理；其中，内存分配粒度可被配置；
当所述可信执行环境触发二阶段缺页时，所述安全监控器检查位图，并找到一个空闲的内存组，将其中的内存页分配给机密虚拟机，并将其中一个内存页缺页地址建立映射，剩余的内存页作为缓存供后续的缺页使用，并在缓存用尽后向所述安全监控器申请新的可信内存。
本发明进一步地设置，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
当所述可信执行环境需要与所述富执行环境共享内存时，对相应的物理内存进行标记，在机密虚拟机触发二阶段缺页中断时，根据二阶段页表中的标记判断缺页的内存是否是共享内存页，若是，则将缺页转给富执行环境进行处理；其中，所述富执行环境会为共享内存页配置物理内存，并在返回机密虚拟机之前将物理内存页注册到安全监控器，并通过安全监控器对机密虚拟机的缺页进行映射；
当所述可信执行环境之间进行内存共享时，源可信执行环境实例向安全监控器注册内存共享请求，当目标可信执行环境实例向安全监控器注册接受共享内存的回复后，源可信执行环境实例与目标可信执行环境实例建立内存共享，安全监控器将源可信执行环境实例的共享内存重映射至目标可信执行环境实例。
本发明进一步地设置，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
创建飞地物理地址空间，以映射飞地的内存数据，其中，所有的飞地共享一个飞地物理地址空间；
当创建飞地并申请安全内存时，对机密虚拟机地址空间的相应内存页进行标记，并在二阶段页表中取消相应内存页的权限，以在机密虚拟机地址空间中构建一个内存隔离域；
根据安全内存在机密虚拟机地址空间的地址偏移将安全内存中的飞地内存页重映射到飞地物理地址空间中，以使飞地内存处于一个单独的地址空间中。
本发明进一步地设置，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
将机密虚拟机地址空间中的相应内存重映射至飞地物理地址空间。
第二方面，本发明还提供了一种计算机设备，包括处理器与存储器，所述处理器上存储有计算机程序，所述计算机程序被所述处理器执行时用于实现上述所述的可信执行环境实现方法。
第三方面，本发明还提供了一种存储介质所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述所述的可信执行环境实现方法。
本发明所提供的一种可信执行环境实现方法、计算机设备及存储介质，方法包括：安全监控器响应用户请求，创建可信执行环境实例；其中，所述可信执行环境实例包括机密虚拟机、管理态飞地与用户态飞地；在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换，并进行安全检查；安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享。本发明通过在虚拟机管理器与机密虚拟机之外增加飞地，可以实现对多种TEE抽象的支持，以安全监控器对虚拟机管理器、机密虚拟器与飞地之间的状态进行切换与安全检查，可对信执行环境的CPU状态进行保存和恢复，提高了可信执行环境的安全性，并通过安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享，实现了可信执行环境与富执行环境之间以及机密虚拟机内飞地的内存隔离与共享，能够防止未经安全验证的恶意虚拟机内核侵害和泄露用户应用中的敏感数据，进一步提高了可信执行环境的安全性。
附图说明
为了更清楚的说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图示出的结构获得其他的附图。
图1是本发明中可信执行环境实现方法的流程示意图。
图2是本发明中RISC-V平台可信执行环境系统的架构图。
图3是本发明中可信执行环境抽象执行流示意图。
图4是本发明中机密虚拟机与飞地内存模型示意图。
具体实施方式
本发明提供一种可信执行环境实现方法、计算机设备及存储介质，为使本发明的目的、技术方案及效果更加清楚、明确，以下参照附图并举实例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
在实施方式和申请专利范围中，除非文中对于冠词有特别限定，否则“一”、“一个”、“所述”和“该”也可包括复数形式。若本发明实施例中有涉及“第一”、“第二”等的描述，则该“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。
应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。
另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。
可信执行环境技术作为机密计算（一种通过在基于硬件的可信执行环境中执行计算过程的方式，为使用中的数据提供保护的计算模式）的支撑技术之一。TEE的抽象层次从最初面向传统计算的基于进程的方案，如Intel SGX（Software Guard Extensions，软件防护扩展），逐渐演化为面向云计算的基于虚拟机的解决方案，如Intel TDX（Trust DomainExtensions，信任域扩展）。目前主要的面向进程的TEE方案有三种，一种是直接利用物理内存保护（Physical Memory Protection，PMP）隔离内存域来构建能够支持包含管理模式的Enclave，第二种则是对硬件和操作系统进行了较大的修改，通过位操作系统构建受控的页表，使其无法访问安全页，为Enclave的构建提供了灵活细粒度的内存隔离原语，该方式可以依次实现多个用户态Enclave，并能够依靠引入的MMT（Mountable Merkle Tree，可挂载默克尔树）机制实现内存的完整性保护，第三种是通过扩展CPU核心和修改总线仲裁控制逻辑实现了内存隔离和外设绑定，依靠这些自定义的硬件原语，可以构建用户空间Enclave、内核空间Enclave以及子空间Enclave。
Enclave和机密虚拟机技术架构逐渐应用于区块链、大数据、人工智能等领域，成为构建其他技术的安全基石。然而，对于当前的TEE架构能否真正适合作为其他技术的安全基石，仍有待考证，特别是考虑到目前TEE架构存在以下一些缺陷：
1. 缺乏内部隔离机制。
在当前的TEE架构中，机密虚拟机（运用在机密运算中的虚拟机）这种VM级的隔离要比Enclave这种进程级的隔离粒度大的多。目前机密虚拟机大部分还是运行一些宏内核操作系统，比如Linux，这使得其内部通常包含一些安全性难以审计的第三方的软件、库和驱动等。虽然机密虚拟机能够防御来自其外部的特权软件的侵害，但其内部仍然面临与外部非虚拟化环境同样的安全问题，若机密虚拟机中未经安全验证的恶意虚拟机内核则可能会侵害和泄露用户应用中的敏感数据。
2. 缺乏对TEE多抽象层的支持。
目前现有的TEE架构都针对单一的抽象层次进行设计，这导致其难以直接应用于其他抽象层级的任务。例如，尽管目前已经有很多工作能够实现在软件防护扩展飞地中运行Library OS（单内核操作系统），但想在Enclave中运行一个需要完整硬件抽象的通用操作系统几乎是不可能的。同样的，在机密虚拟机中实现类似软件防护扩展飞地的用户态隔离也需要付出大量努力。即使有一些平台能够同时支持多种TEE抽象，比如TDX和SGX，这些技术利用的底层机制也差异较大，增大了硬件复杂度并且这些技术之间也缺乏联动。目前仍然缺乏能够同时满足不同抽象层级任务的TEE架构。
3. 灵活性和安全性缺陷。
大部分TEE架构在灵活性和安全性方面仍然有缺陷。目前大部分TEE架构的构建都基于闭源的商业CPU硬件安全扩展，这导致其安全性难以审计并且在出现硬件漏洞后很难进行及时修复。而一些开源的TEE架构则大都采用了侵入式的设计模式，需要对CPU或者系统级芯片（System on Chip，SOC）进行大量修改，或者需要大量软件的适配，这造成了硬件兼容性问题，导致了其实际可应用性的下降。除此之外，目前的TEE架构普遍受到其硬件安全机制的限制。例如Intel SGX受限于飞地页面缓存（Enclave Page Cache，EPC）页面的限制（92MB实际可用内存）。而开源的enclave的数量则受限于PMP条目，并且由于受限于PMP的静态隔离特性而难以实现灵活的共享内存模型。
针对上述技术问题，本发明提供一种可信执行环境实现方法、计算机设备及存储介质，能够实现对可信执行环境CPU和内存的机密性、完整性保护，防止受到控制信道攻击的影响，并能够支持多种TEE抽象，包括机密虚拟机、S-Enclave（管理态飞地）和U-Enclave（用户态飞地）。另外，在机密虚拟机内部实现了内部隔离机制，能够在机密虚拟机内部运行Enclave,解决当前机密虚拟机普遍自身隔离粒度较大的问题，能够防止未经安全验证的恶意虚拟机内核侵害和泄露用户应用中的敏感数据，同时实现了TEE以及REE（RichExecution Environment，富执行环境）以及TEE之间的内存共享。
请同时参阅图1至图4，本发明提供了一种可信执行环境实现方法的较佳实施例。
在一些实施例中，如图1所示，本发明提供了一种可信执行环境实现方法，其包括步骤：
S100、安全监控器响应用户请求，创建可信执行环境实例；其中，所述可信执行环境实例包括机密虚拟机、管理态飞地与用户态飞地；
具体地，请集合图2与图3，在精简指令集架构(Reduced Instruction SetComputer，RISC)中， RISC-V为第五代精简指令集架构，在RISC-V平台中包括可信执行环境与富执行环境两部分，可信执行环境中包括机密虚拟机与Enclave，富执行环境包括虚拟机管理器（Hypervisor），虚拟机管理器包括虚拟机模拟器与操作系统内核。所述虚拟机模拟器用于为机密虚拟机提供模拟设备，操作系统内核用于负责调度CPU，以及对安全监视器（Secure Monitor，SM）中可信执行环境状态接口的调用。机密虚拟机用于运行需要完整硬件抽象的通用操作系统。所述Enclave用于运行进程级的机密任务。所述安全监控器运行在最高特权级机器模式（M模式），具有最高权限，是整个系统的可信基。所述可信执行环境属于可信部分，运行在虚拟化模式中，包括虚拟监管者（Virtual Supervisor，VS）和虚拟用户（Virtual User，VU）两个特权级。所述可信执行环境的属主对其具有操作权限，所述富执行环境可以通过所述安全监控器提供的接口对可信执行环境进行控制操作，例如可信执行环境的初始化、运行、暂停等，同时，所述可信执行环境可以通过接口实现获取自身度量报告、平台随机数等。所述富执行环境是非可信部分，其中操作系统内核包括虚拟化模块（Kernel-based Virtual Machine，KVM）、调度器、设备驱动以及系统文件等，所述虚拟机模拟器（Quick Emulator，QEMU）运行在用户模式（U模式），能够为机密虚拟机提供模拟设备，所述操作系统内核可以是Linux内核，可对虚拟CPU（virtual CPU，vCPU）的调度、机密虚拟机设备的模拟负责。
安全监控器可以响应用户请求，判断需要创建的TEE类型是机密虚拟机、管理态飞地（S-Enclave）或者用户态飞地（U-Enclave）。在创建机密虚拟机时建立信任链（可信启动），按页粒度加载并度量机密虚拟机内核、设备树文件到可信内存区并构建二阶段页表，在创建S-Enclave时，加载并度量S-Enclave的可信应用和运行时（Runtime，RT）到可信内存区并构建二阶段页表，在创建U-Enclave时，加载并度量U-Enclave的可信应用到可信内存区并构建二阶段页表。
其中，机密虚拟机是VM级的TEE，本实施例中为其提供了完整的硬件抽象，使其能够运行全功能的通用操作系统，比如Linux。每个机密虚拟机根据启动配置包含一个或多个vCPU。SM为Hypervisor提供了一系列管理机密虚拟机及其vCPU的接口，包括机密虚拟机的创建、销毁和vCPU的初始化、运行、暂停等。机密虚拟机在启动时需要对vCPU进行初始化，并在初始化成功之后，运行vCPU。S-Enclave比机密虚拟机更加轻量，其能够运行一个包含S模式的Enclave，这使得该Enclave能够处理一部分系统功能。S-Enclave利用了与机密虚拟机中同样的TEE原语。S-Enclave与机密虚拟机一样需要在SM中实现上下文的切换。同样的，每个S-Enclave也有自己独立的物理地址空间。SM也为S-Enclave提供了与机密虚拟机类似的接口，包括Enclave的启动、停止、销毁等。S-Enclave与机密虚拟机的不同之处在于其没有完整的硬件抽象。比如，虽然S-Enclave像机密虚拟机一样有自己独立的物理地址空间，然而，其地址空间是不完整的，仅有S-Enclave私有内存占据的地址空间是有效的。除此之外，S-Enclave也不像机密虚拟机一样需要完整的IO设备抽象，这些原因就使得在S-Encalve中仅能够运行一个包含部分系统功能的RT，而并不能运行需要完整硬件抽象的操作系统，比如Linux。
U-Enclave是最轻量的TEE环境，其构建机制和运行模式与S-Enclave相同，具有与S-Enclave相同的技术优势，不同之处在于其不包含S模式而仅能运行一个包含U模式的Enclave。U-Enclave同样利用了与机密虚拟机和S-Enclave一样的TEE原语，但在具体的实现策略上有所不同，比如，在中断异常代理中，由于U-Enclave不具备S模式，所以当发生中断和异常时都会转发到SM进行处理。所以为了进一步支持U-Enclave的系统调用，在SM中构建了系统调用代理模块，当U-Enclave中的应用程序需要系统调用时，其需要将系统调用信息写入与APP（应用程序）的共享内存中，然后通过环境调用（Environment Call，ECALL）将控制权转移到SM。之后，SM会根据ECALL判断该次调用是否是系统调用。如果是系统调用，则进一步转发到REE环境，由与该U-Enclave关联的APP进行处理。系统调用的结果同样会写入到共享内存，由U-Enclave进行获取。为了减小SM的可信计算基（Trusted Computing Base，TCB），本发明并没有选择在SM对系统调用的安全性进行保护，因为U-Enclave自身有义务对其系统调用的安全性进行保护，不仅需要通过维护类似元数据状态机的机制来保证系统调用结果的正确性，也需要防止攻击者通过其系统调用模式推断出Enclave内部的机密信息。
因此，在机密虚拟机内，本发明支持两类Enclave的运行，第一类称为U类Enclave，这类Enclave仅包含用户模式部分，U类Enclave类似SGX，仅支持用户态应用的运行，对U类Enclave提供了类似SGX的外部调用（Outside Call，OCALL）支持，其系统调用可以通过共享内存机制由机密虚拟机内的应用代理实现。第二类Enclave是U+S类，这类Enclave与U类Enclave的不同之处在于其自身包含了一个运行在S模式的RT，RT包含了简单的系统功能，能够支持简单的内存管理、系统调用代理等功能。
S200、在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换与恢复，并进行安全检查；
在本实施例中，基于对物理CPU的时间划分，通过安全监控器来实现上下文切换状态的保护。首先，请结合图2与图3，为了防止REE破坏和修改TEE CPU的状态，REE执行流不能直接进入TEE环境，而只能通过安全监控器提供的接口进入。其次，为了防止TEE的CPU状态信息被REE获取到，TEE执行退出时也不能够直接退出到REE环境。所以，REE和TEE环境之间不能有直接的控制流转移。两者之间的状态切换必须经由安全监控器进行代理，由安全监控器实现上下文的切换，并在SM进行安全检查。在由REE进入TEE时，安全监控器会恢复TEECPU寄存器状态，并对需要更新的CPU寄存器状态进行检查。
S300、安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享。
具体地，首先，需要理解的是，在TEE架构设计中，如何保护TEE环境的内存状态，防止特权软件对TEE环境内存状态的破坏是一个关键的安全挑战。大部分TEE架构在解决该问题时往往选择直接利用或扩展底层硬件平台中的物理内存隔离特性。例如，直接选择了利用RISC-V平台中的物理内存保护（Physical Memory Protection，PMP）机制划分内存隔离域来实现对Enclave的内存隔离，每个Enclave需要分配一个PMP Entry（条目）；对底层硬件平台进行了扩展，通过在主内存前修改总线仲裁器逻辑实现对物理内存的访问控制，并进一步基于此实现对Enclave代码和数据的隔离；对page walk（指的是硬件页面寻址过程）进行了修改，并通过引入内存跟踪表（Memory Tracking Table，MTT）实现对物理内存的细粒度保护。
虽然直接利用硬件平台的特性可以方便的实现对TEE内存的隔离，然而，这也对TEE环境产生了限制。例如，由于每个Enclave的内存需要一个PMP条目进行保护，因此，Enclave的数量会受到PMP数量的限制（n-2）。虽然也有工作尝试解决这种数量限制，但也是以产生大量内存碎片并需要引入内存整理操作为代价。并且这种基于内存域划分的内存隔离模型对内存模型产生了限制，Enclave难以支持灵活的动态内存和内存共享。而对硬件进行修改，比如添加第三级页表实现对物理内存的细粒度访问的控制方案，能够很大程度上解决静态内存域划分带来的问题。然而这类方案会带来硬件复杂度的上升，并且导致软件兼容性的下降，并且很可能会带来额外的访存开销。
为了避免直接利用硬件静态内存隔离原语和修改硬件所带来的问题，本发明采用了基于静态内存隔离和分页辅助的内存隔离方案，在不修改硬件的基础上实现灵活高效的内存隔离。选择利用PMP机制来划分出内存隔离域，但并不是将每个内存隔离域赋予单独的TEE环境，而是构建了一个可信内存管理模块来对内存隔离域中的可信内存进行管理，并通过可信内存模块配置二阶段页表实现TEE环境内存之间的隔离。基于这种PMP和二阶段分页结合的内存隔离方案充分利用了PMP的物理内存隔离特性和分页机制的灵活性，能够为TEE环境提供安全、灵活且高效的内存隔离方案，并为REE与TEE之间以及TEE之间的内存共享提供基础。在本实施例中，首先会申请一段连续物理内存作为可信内存区，并将其注册到SM，由SM分配PMP对整个连续内存进行保护，并由SM进行管理和分配。SM会控制二阶段缺页的处理，并负责可信内存页的分配以及TEE环境二阶段页表的创建和管理。
在上述技术方案中，在硬件上，本发明并没有进行修改，以实现最大的兼容性。同时，也不依赖于特定的硬件比如可信平台模块（Trusted Platform Module，TPM），而仅依赖当前RISC-V提供的一些安全机制，主要包括PMP、虚拟化扩展和trap（陷阱）代理，来实现对TEE CPU和内存状态的保护和隔离。对于这些安全机制，本发明并没有直接应用，而是选择进行组合设计，以充分发挥其各自的优势，提供最大的灵活性。相对于现有技术，本发明通过在虚拟机管理器与机密虚拟机之外增加Enclave，可以实现对多种TEE抽象的支持，以安全监控器对虚拟机管理器、机密虚拟器与Enclave之间的状态进行切换与安全检查，可对信执行环境的CPU状态进行保存和恢复，提高了可信执行环境的安全性，并安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享，实现了可信执行环境与富执行环境之间以及机密虚拟机内Enclave的内存隔离与共享，能够防止未经安全验证的恶意虚拟机内核侵害和泄露用户应用中的敏感数据，进一步提高了可信执行环境的安全性。
在一些实施例中，所述在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换与恢复，并进行安全检查的步骤包括：
S210、在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查；
S220、在可信执行环境退出至富执行环境时，安全监控器对可信执行环境中的敏感寄存器进行清空并对微架构信息进行清除。
在本实施例中，为了防止REE在进入TEE环境时注入恶意的寄存器数据，需要在进入TEE环境时对寄存器状态进行消毒。TEE的寄存器可以分为两类：一类是保存TEE执行状态的通用寄存器，第二类是能够控制和影响TEE运行状态的控制状态寄存器。通用寄存器是共享的，因此在机密虚拟机上下文切换时，需要保存和恢复整个通用寄存器组的状态。例如，在TEE进入时，需要保存REE的通用寄存器状态，以便在TEE退出时进行恢复。同时，还需要恢复TEE目标CPU的通用寄存器状态，以确保TEE的正常运行。对于控制状态寄存器，在RISC-V的虚拟化架构下，大多数控制状态寄存器都有各自的副本，因此TEE与REE不需要共享同一组控制状态寄存器。然而，由于REE在执行期间可能修改虚拟机的控制寄存器的状态，因此在上下文切换时仍需要保存和恢复控制状态寄存器的状态。
对TEE CPU的保护除了保护其寄存器状态外，还需要保护其微架构状态信息。CPU中的微架构结构包括Cache（缓存）和快表（Translation Lookaside Buffer，TLB）等在REE和TEE环境是共享的，REE可能会利用TEE环境残留在CPU微架构中的状态信息发起侧信道攻击，破坏TEE环境的机密性。为了防止信息泄露，需要在TEE和REE之间的状态切换时对敏感的寄存器状态和微架构状态信息进行清除。此外，攻击者还可能在TEE运行期利用共享的Cache结构发起侧信道攻击，针对这类攻击，需要借助硬件平台提供的安全能力，比如L2Cache控制器来保护TEE的Cache。
在一些实施例中，所述在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查的步骤包括：
S211、配置中断异常代理寄存器，当可信执行环境中发生中断和异常时，将可信执行环境自身可处理的中断和异常代理给可信执行环境，并对可信执行环境不可处理的中断和异常进行处理。
在本实施例中，由于TEE环境内存受到PMP机制的保护，所以可以防止REE通过执行TEE环境中的代码从而将控制流转移到TEE。REE可以通过SM指定的接口以受控的方式进入TEE环境，这些接口包括暂停、恢复TEE执行流，获取TEE环境的度量值等。进一步，为了防止TEE环境退出时执行流被REE获取，在SM实现了对TEE环境的中断异常代理控制。在RISC-V架构中，所有的中断和异常都会默认进入M模式，通过配置中断异常代理寄存器则可以实现将其代理到其它的低特权级。TEE环境中的中断和异常可以分为两类：一类是TEE环境自身能够处理的，另一类是TEE环境自身无法处理的。对于第一类中断和异常（如一阶段缺页异常），通过将其代理给TEE自身，由TEE的内核进行处理。对于第二类异常（如二阶段缺页异常），则是由SM进行处理，通过这种方式，无论何时发生中断和异常，控制流都无法被非可信的REE环境截获。需要说明的是，在系统运行后，当遇到二阶段缺页异常时，会被SM捕获，交由SM中的内存管理模块进行处理，SM会为每个机密虚拟机配置单独的物理地址空间，并通过控制二阶段页表实现机密虚拟机之间的隔离。
在一些实施例中，所述在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查的步骤还包括：
S212、当发生异常导致可信执行环境退出并通过富执行环境处理后，在可信执行环境恢复运行时对CPU寄存器状态进行检查，并在可信执行环境退出时对敏感寄存器进行清空。
具体地，由于部分异常导致TEE退出并需要REE环境进行处理，例如内存映射I/O（Memory-Mapped I/O，MMIO）和部分VS 环境调用，这些异常发生后，在TEE恢复运行时需要对CPU的寄存器状态进行检查，以确保REE无法恶意注入错误的寄存器数据。在TEE退出时，为了防止CPU寄存器信息状态被REE获取到，因此同样需要对敏感的寄存器进行清空。
在一些实施例中，安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤包括：
S310、当所述安全监控器注册完成一段连续物理内存作为可信内存区后，所述安全监控器申请一个位图对连续物理内存的状态进行记录，并根据位图对整个可信内存区的内存进行管理；其中，内存分配粒度可被配置；
S320、当所述可信执行环境触发二阶段缺页时，所述安全监控器检查位图，并找到一个空闲的内存组，将其中的内存页分配给机密虚拟机，并将其中一个内存页缺页地址建立映射，剩余的内存页作为缓存供后续的缺页使用，并在缓存用尽后向所述安全监控器申请新的可信内存。
具体地，当特权用户申请了一段连续物理内存并向SM注册，SM便会申请一个bitmap（位图）对这段连续物理内存的状态进行记录。SM会依靠bitmap实现对整个可信内存区内存的管理。bitmap中的一位代表了可信内存区中连续16KB内存页的分配状态。
其中，内存分配粒度是可配置的，而非按单个内存页进行分配，通过适当提高可信内存分配粒度既可以减小bitmap的大小，又可以避免频繁去请求内存分配所带来的开销，实现了空间与时间上的双优。在一种实现方式中，内存分配粒度可以被配置为4个可信内存页。当TEE触发二阶段缺页时，SM会检查bitmap，找到一个空闲的内存组，然后将其中的内存页分配给虚拟机，并将其中一个内存页缺页地址建立映射，而将剩余的内存页作为缓存供后续的缺页使用，并只有在缓存用尽后才会向SM申请新的可信内存，以通过提前缓存内存页减小后续寻找可用内存的开销。
在一些实施例中，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
S330、当所述可信执行环境需要与所述富执行环境共享内存时，对相应的物理内存进行标记，在机密虚拟机触发二阶段缺页中断时，根据二阶段页表中的标记判断缺页的内存是否是共享内存页，若是，则将缺页转给富执行环境进行处理；其中，所述富执行环境会为共享内存页配置物理内存，并在返回机密虚拟机之前将物理内存页注册到安全监控器，并通过安全监控器对机密虚拟机的缺页进行映射；
S340、当所述可信执行环境之间进行内存共享时，源可信执行环境实例向安全监控器注册内存共享请求，当目标可信执行环境实例向安全监控器注册接受共享内存的回复后，源可信执行环境实例与目标可信执行环境实例建立内存共享，安全监控器将源可信执行环境实例的共享内存重映射至目标可信执行环境实例。
具体地，在建立TEE环境内存隔离机制之后，需要同时考虑构建内存共享机制，以支持数据在TEE环境下的高效流通。需要说明的是，TEE环境下的内存共享可以细分为两种场景，首先是TEE环境和REE环境之间的内存共享场景，这种通常存在于TEE环境请求REE环境的服务中。比如，第一种是通过共享内存传递edge call（边缘调用）参数来实现将syscall（系统调用）代理给REE处理。第二种则是TEE环境之间的内存共享场景，通过利用TEE环境与REE环境之间的共享内存也可以建立TEE环境之间的内存共享，然而，这种共享内存很可能会受到非可信REE环境的攻击，因此需要引入额外的加密和验证机制。在TEE环境之间直接建立内存共享是一种更高效安全的方式。然而，当前的 TEE方案，由于内存静态隔离机制的限制，在不同Enclave之间实现内存共享非常困难，对于进一步实现非连续内存共享以及内存共享权限控制则更加困难。
本发明同样需要支持以上两类内存共享场景，以支持不同抽象层TEE环境丰富的内存共享场景。在具体实施时，可以通过SM对可信内存以及页表的管理权限，通过页表标记与重映射实现TEE与REE以及TEE之间的内存共享。
当所述可信执行环境需要与所述富执行环境共享内存时，可以利用二阶段分页页表项（(Page Table Entry，PTE）中的保留位。对相应物理内存做标记，将目标共享内存页所对应的页表项中的保留位置为TEE_MEM_SHARED（一个自定义的标志位，代表01）。当机密虚拟机触发二阶段缺页中断时，SM会根据页表中的标记判断缺页的内存页是否是共享内存页，如果是共享内存页则将该缺页需求转发给REE进行处理。REE会为共享内存页分配物理内存，并在返回机密虚拟机之前注册将该物理内存页注册到SM，并由SM实现机密虚拟机的缺页映射。
其中，机密虚拟机可以通过共享内存接口申请与虚拟机管理器的共享内存，借由此可以实现VirtIO机制，使机密虚拟机中的驱动能够更高效的与Hypervisor中的模拟设备进行通信。除此之外，机密虚拟机也可以申请与其它机密虚拟机之间的共享内存，借此可以构建类似XenSocket的虚拟机之间的低延迟、高吞吐量的通信机制。
当所述可信执行环境之间进行内存共享时，可以建立一个握手机制。首先，源TEE会向SM注册其内存共享请求，该请求包含了其共享内存的起始地址和大小并包含了目标TEE的ID（标识）。之后，只有当目标TEE也向SM注册其接受共享内存的回复之后，源TEE和目标TEE之间的共享内存才会建立。之后，SM才会将源TEE的共享内存重映射到目标TEE。一旦源TEE或者目标TEE两者中的一个终止了共享，SM便会取消TEE共享内存的映射。
在一些实施例中，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
S350、创建飞地物理地址空间，以映射飞地的内存数据，其中，所有的飞地共享一个飞地物理地址空间；
S360、当创建飞地并申请安全内存时，对机密虚拟机地址空间的相应内存页进行标记，并在二阶段页表中取消相应内存页的权限，以在机密虚拟机地址空间中构建一个内存隔离域；
S370、根据安全内存在机密虚拟机地址空间的地址偏移将安全内存中的飞地内存页重映射到飞地物理地址空间中，以使飞地内存处于一个单独的地址空间中。
对于机密虚拟机内存与飞地内存隔离中，所述内存隔离与共享模块通过对二阶段页表的权限控制构建飞地内存隔离机制，请结合图4，具体为：在机密虚拟机的地址空间之外，创建一个影子地址空间，即飞地物理地址空间，用以映射飞地的内存数据，可信执行环境中所有的飞地共享同一个飞地物理地址空间，即Enclave地址空间。当创建飞地并申请安全内存时，对机密虚拟机地址空间的相应内存页进行标记，其后在二阶段页表中取消相应内存页的权限，从而可以在机密虚拟机地址空间中构建一个内存隔离区域，使得机密虚拟机无法访问安全内存中的数据。与此同时，根据安全内存在机密虚拟机地址空间的地址偏移将安全内存中的飞地内存页（即Enclave内存页）重映射到飞地物理地址空间中，使得飞地内存处于一个单独的地址空间中，从而保证了飞地内存与机密虚拟机内存的隔离。在运行机密虚拟机时，由于飞地内存页权限都被取消，因此，机密虚拟机没有权限读取或执行飞地内存。当Enclave运行时，机密虚拟机地址空间会切换至飞地物理地址空间。在飞地址物理空间中，由于飞地以外的数据并没有被映射，使得飞地只能够访问器其自身的数据，而不能访问外部机密虚拟机中的内存数据。
在一些实施例中，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
S380、将机密虚拟机地址空间中的相应内存重映射至飞地物理地址空间。
具体地，飞地在运行时也需要共享内存的支持，基于共享内存飞地可以实现与应用的数据传递，并能够进一步支持飞地的OCALL调用。在机密虚拟机中，如图4所示，通过将机密虚拟机地址空间中的相应内存重映射到飞地物理地址空间实现飞地与机密虚拟机的内存共享。在二阶段内存页重映射建立完毕之后，机密虚拟机和飞地便都能够同时对共享内存进行访问。基于这种基于内存重映射的飞地内存共享机制，可以在机密虚拟机与飞地之间实现非连续页粒度的内存页共享机制。
需要说明的是，由于S-Enclave利用了基于虚拟化构建的TEE原语，这使得其具有一般飞地所不具备的优势。首先，由于S-Enclave的内存隔离是基于PMP和二阶段页表实现的，这使得其数量不像以往的飞地架构一样受到硬件安全资源的限制。并且由于SM完全控制S-Enclave的二阶段页表，这使得其能够通过物理地址重映射实现与其它S-Enclave之间的内存共享，并进一步通过对二阶段页表的权限位控制实现灵活的内存共享模型。
需要说明的是，安全监控器的接口可以设置在虚拟化模块中，以实现对可信执行环境的状态控制。对于机密虚拟机来说，如果其模拟设备需要高效的IO（比如virtio）或需要支持模拟的存储器直接访问(Direct Memory Access，DMA)操作，也可以通过添加申请共享内存接口来实现。并且，由于具体的安全策略是由安全监控器的固件进行控制，所以本发明的安全策略是可升级可配置的。
在一些实施例中，所述安全监控器中的部分功能模块可以转移至虚拟机管理器中，在虚拟机管理器构建一个机密虚拟机管理器，并在虚拟机管理器中对构建的机密虚拟机管理器进行隔离。
在一些实施例中，本发明还提供了一种计算机设备，包括处理器与存储器，所述处理器上存储有计算机程序，所述计算机程序被所述处理器执行时用于实现以下方法中的步骤：
安全监控器响应用户请求，创建可信执行环境实例；其中，所述可信执行环境实例包括机密虚拟机、管理态飞地与用户态飞地；
在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换与恢复，并进行安全检查；
安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享。
在一些实施例中，本发明还提供了一种存储介质，即计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现以下方法中的步骤：
安全监控器响应用户请求，创建可信执行环境实例；其中，所述可信执行环境实例包括机密虚拟机、管理态飞地与用户态飞地；
在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境以及可信执行环境实例之间的状态切换与恢复，并进行安全检查；
安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境以及可信执行环境实例之间的内存进行隔离与共享。
综上所述，本发明所提供的一种可信执行环境实现方法、计算机设备及存储介质，具有以下有益效果：
实现资源管理与安全检查的分离来减小TCB，安全监控器仅包含与安全相关的核心功能，而对于vCPU的调度、设备模拟等功能仍然由虚拟机管理器负责。为了实现最大的兼容性，在硬件上，本发明既没有对硬件进行修改。对于这些安全机制，并没有直接应用，而是选择进行组合设计，以充分发挥其各自的优势，提供最大的灵活性；
在机密虚拟机内部实现了内部隔离机制，能够在机密虚拟机内部运行Enclave,解决当前机密虚拟机普遍自身隔离粒度较大的问题，能够防止未经安全验证的恶意虚拟机内核侵害和泄露用户应用中的敏感数据；
基于RISC-V平台硬件安全原语实现了TEE架构，能够实现对TEE CPU和内存的机密性、完整性保护，并能够支持多种TEE抽象，包括机密虚拟机、S-Enclave和U-Enclave；
为TEE设计了共享内存机制，可以方便高效的实现TEE与REE以及TEE之间的内存共享；
机密虚拟机的二阶段缺页、核间中断等信息都会被安全监控器进行截获，敏感信息不会泄露到可信边界外，不会受到控制信道攻击的影响。
应当理解的是，本发明的应用不限于上述的举例，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，所有这些改进和变换都应属于本发明所附权利要求的保护范围。
Claims (9)
1.一种可信执行环境实现方法，其特征在于，包括：
安全监控器响应用户请求，创建可信执行环境实例；其中，所述可信执行环境实例包括机密虚拟机、管理态飞地与用户态飞地；
在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境、以及可信执行环境实例之间的状态切换与恢复，并进行安全检查；
安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境、以及可信执行环境实例之间的内存进行隔离与共享；
所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境、以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
创建飞地物理地址空间，以映射飞地的内存数据；
当创建飞地并申请安全内存时，对机密虚拟机地址空间的相应内存页进行标记，并在二阶段页表中取消相应内存页的权限，以在机密虚拟机地址空间中构建一个内存隔离域；
根据安全内存在机密虚拟机地址空间的地址偏移将安全内存中的飞地内存页重映射到飞地物理地址空间中，以使飞地内存处于一个单独的地址空间中。
2.根据权利要求1所述的可信执行环境实现方法，其特征在于，所述在可信执行环境运行时，安全监控器控制富执行环境与所述可信执行环境、以及可信执行环境实例之间的状态切换与恢复，并进行安全检查的步骤包括：
在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查；
在可信执行环境退出至富执行环境时，安全监控器对可信执行环境中的敏感寄存器进行清空并对微架构信息进行清除。
3.根据权利要求2所述的可信执行环境实现方法，其特征在于，所述在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查的步骤包括：
配置中断异常代理寄存器，当可信执行环境中发生中断和异常时，将可信执行环境自身可处理的中断和异常代理给可信执行环境，并对可信执行环境不可处理的中断和异常进行处理。
4.根据权利要求2所述的可信执行环境实现方法，其特征在于，所述在富执行环境进入可信执行环境时，安全监控器恢复可信执行环境的CPU寄存器状态，并对需要更新的CPU寄存器状态进行检查的步骤还包括：
当发生异常导致可信执行环境退出并通过富执行环境处理后，在可信执行环境恢复运行时对CPU寄存器状态进行检查，并在可信执行环境退出时对敏感寄存器进行清空。
5.根据权利要求1所述的可信执行环境实现方法，其特征在于，安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境、以及可信执行环境实例之间的内存进行隔离与共享的步骤包括：
当所述安全监控器注册完成一段连续物理内存作为可信内存区后，所述安全监控器申请一个位图对连续物理内存的状态进行记录，并根据位图对整个可信内存区的内存进行管理；其中，内存分配粒度能够被配置；
当所述可信执行环境触发二阶段缺页时，所述安全监控器检查位图，并找到一个空闲的内存组，将其中的内存页分配给机密虚拟机，并将其中一个内存页缺页地址建立映射，剩余的内存页作为缓存供后续的缺页使用，并在缓存用尽后向所述安全监控器申请新的可信内存。
6.根据权利要求1所述的可信执行环境实现方法，其特征在于，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境、以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
当所述可信执行环境需要与所述富执行环境共享内存时，对相应的物理内存进行标记，在机密虚拟机触发二阶段缺页中断时，根据二阶段页表中的标记判断缺页的内存是否是共享内存页，若是，则将缺页转给富执行环境进行处理；其中，所述富执行环境会为共享内存页配置物理内存，并在返回机密虚拟机之前将物理内存页注册到安全监控器，并通过安全监控器对机密虚拟机的缺页进行映射；
当所述可信执行环境之间进行内存共享时，源可信执行环境实例向安全监控器注册内存共享请求，当目标可信执行环境实例向安全监控器注册接受共享内存的回复后，源可信执行环境实例与目标可信执行环境实例建立内存共享，安全监控器将源可信执行环境实例的共享内存重映射至目标可信执行环境实例。
7.根据权利要求1所述的可信执行环境实现方法，其特征在于，所述安全监控器注册一段连续物理内存作为可信内存区，并配置二阶段页表对可信执行环境与富执行环境、以及可信执行环境实例之间的内存进行隔离与共享的步骤还包括：
将机密虚拟机地址空间中的相应内存重映射至飞地物理地址空间。
8.一种计算机设备，包括处理器与存储器，其特征在于，所述处理器上存储有计算机程序，所述计算机程序被所述处理器执行时用于实现权利要求1-7任一项所述的可信执行环境实现方法。
9.一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-7任一项所述的可信执行环境实现方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311850601.7A CN117494108B (zh) | 2023-12-29 | 2023-12-29 | 可信执行环境实现方法、计算机设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311850601.7A CN117494108B (zh) | 2023-12-29 | 2023-12-29 | 可信执行环境实现方法、计算机设备及存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117494108A CN117494108A (zh) | 2024-02-02 |
| CN117494108B true CN117494108B (zh) | 2024-05-31 |
Family
ID=89669385
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311850601.7A Active CN117494108B (zh) | 2023-12-29 | 2023-12-29 | 可信执行环境实现方法、计算机设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117494108B (zh) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109558211A (zh) * | 2018-11-27 | 2019-04-02 | 上海瓶钵信息科技有限公司 | 保护可信应用与普通应用的交互完整性和保密性的方法 |
| CN113703924A (zh) * | 2021-09-22 | 2021-11-26 | 上海交通大学 | 基于可信执行环境的安全虚拟机系统设计方法及系统 |
| CN116701251A (zh) * | 2023-06-02 | 2023-09-05 | 支付宝(杭州)信息技术有限公司 | 在计算设备中管理tlb的方法和对应计算设备 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11888972B2 (en) * | 2020-02-26 | 2024-01-30 | Red Hat, Inc. | Split security for trusted execution environments |
-
2023
- 2023-12-29 CN CN202311850601.7A patent/CN117494108B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109558211A (zh) * | 2018-11-27 | 2019-04-02 | 上海瓶钵信息科技有限公司 | 保护可信应用与普通应用的交互完整性和保密性的方法 |
| CN113703924A (zh) * | 2021-09-22 | 2021-11-26 | 上海交通大学 | 基于可信执行环境的安全虚拟机系统设计方法及系统 |
| CN116701251A (zh) * | 2023-06-02 | 2023-09-05 | 支付宝(杭州)信息技术有限公司 | 在计算设备中管理tlb的方法和对应计算设备 |
Non-Patent Citations (1)
| Title |
|---|
| TEESec:Pre-Silicon Vulnerability Discoverey for Trusted Execution Environments;Yinqian Zhang et al.;《ISCA23》;20230621;第1-15页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117494108A (zh) | 2024-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11467982B2 (en) | Virtualization-based platform protection technology | |
| Champagne et al. | Scalable architectural support for trusted software | |
| US9846787B2 (en) | System and method for implementing a trusted dynamic launch and trusted platform module (TPM) using secure enclaves | |
| Jin et al. | Architectural support for secure virtualization under a vulnerable hypervisor | |
| US10459850B2 (en) | System and method for virtualized process isolation including preventing a kernel from accessing user address space | |
| US9983894B2 (en) | Method and system for providing secure system execution on hardware supporting secure application execution | |
| US10860718B2 (en) | Protecting computer systems used in virtualization environments against fileless malware | |
| US7418584B1 (en) | Executing system management mode code as virtual machine guest | |
| US10095862B2 (en) | System for executing code with blind hypervision mechanism | |
| US20080077767A1 (en) | Method and apparatus for secure page swapping in virtual memory systems | |
| CN108205502B (zh) | 轻量可信任务 | |
| US8327415B2 (en) | Enabling byte-code based image isolation | |
| Williams et al. | CPU support for secure executables | |
| Zhao et al. | Minimal kernel: an operating system architecture for {TEE} to resist board level physical attacks | |
| Vahidi et al. | VETE: Virtualizing the Trusted Execution Environment | |
| CN117494108B (zh) | 可信执行环境实现方法、计算机设备及存储介质 | |
| Park et al. | Libmpk: software abstraction for Intel memory protection keys | |
| Choi et al. | S-OpenSGX: A system-level platform for exploring SGX enclave-based computing | |
| Chen et al. | Security and Performance in the Delegated User-level Virtualization | |
| EP4202654A1 (en) | Efficient exception handling in trusted execution environments | |
| Elwell et al. | Hardening extended memory access control schemes with self-verified address spaces | |
| Lee | Scalable architectural support for trusted software | |
| Srinivasan et al. | MIvmm: A micro VMM for development of a trusted code base | |
| Fang et al. | TRIOB: A Trusted Virtual Computing Environment Based on Remote I/O Binding Mechanism | |
| Fuko | Using Verification to Disentangle Secure-enclave Hardware from Software |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |