动机
现有的TEE存在问题：
- 需要硬件更改
- 闭源，难以审查
- 飞地以固定模式运行，难以灵活适应不同工作负载
设计目标
- G1：最小化硬件修改
- 硬件虚拟化+TPM
- 跨平台
- G2：容易开发
- SGX兼容
- 移植现有的SGX程序只需要很少或不需要代码更改
- G3：灵活的飞地模式
- 更好地满足特定飞地工作负载的需求
威胁模型
- 系统最初正常：启动后可能是被损害
- 恶意软件：应用，OS内核，飞地恶意软件
- 特定物理攻击：冷启动，总线窥探攻击
- 特定侧信道攻击：基于页表的攻击
- 不考虑：拒绝服务攻击，其他侧信道（cache timing,speculative execution）
概述
- RustMonitor：VMX root,ring-0
- Normal VM：VMX non-root，ring-0&ring-3
- Enclave：灵活性
- VMX non-root, ring-3 (GU-Enclave)
- VMX non-root, ring-0 (P-Enclave)
- VMX root, ring-3 (HU-Enclave)
设计目标
内存管理和保护
现有设计，飞地的页表由不可信OS管理，存在内存映射攻击（操纵地址映射）
SGX扩展Page Missing Handler (PMH)并引入新的元数据EPCM用于TLBmiss时的额外安全检查；然而飞地页表错误由OS处理，这种设计容易收到基于页表的攻击，比如受控信道攻击；SGX2支持动态飞地内存管理，通过OCALL发送EDMM请求给SGX driver，driver不可信，因此需要大量检查，涉及到Enclave模式切换，开销大
上述问题的根源在于，飞地的页表和页故障由OS管理，在HyperEncalave中，实现飞地页表的隔离，RustMonitor代替OS来管理飞地的页表和页故障，正常VM的页表仍然由OS管理。
上述方法存在新的挑战：enclave可以访问普通应用程序的整个地址空间。因此，普通应用程序的页表映射发生改变的时候，更新的映射需要同步到enlave的页表
为了消除同步开销，在应用空间预分配和enclave共享的marshalling buffer，enclave和application之间的数据交换通过marshalling buffer进行，这样application的内存映射就不需要包含在enclave的页表中，这种设计还减轻了enclave的恶意软件攻击，因为enclave无法访问application的地址空间
内存隔离机制，normal VM的application内存通过Nested paging管理，enclave内存通过Nested paging或正常额1级地址转换管理。满足以下安全需求：
- R1：不允许主OS和application访问属于 RustMonitor 和 enclave 的物理内存。
- R2：不允许安全区访问属于 RustMonitor 和其他安全区的物理内存。它被设计为只能访问与不受信任的应用程序共享的特定内存区域，以便进行参数传递。
- R3：从恶意外围设备到属于 RustMonitor 和Enclave的物理内存的DMA访问不被允许。为防止此类攻击，HyperEnclave 在IOMMU的支持下限制了外围设备使用的物理内存。
灵活的飞地操作模式
- 大量不同的应用需求不同，TEE需要更好的满足不同飞地工作负载的需求
大多数现有的TEE运行在固定模式（Intel SGX,TrustVisor,Secage)，不能使用于不同应用；用户模式的飞地不能访问特权资源，需要切换到不可信代码，从而访问特权资源或处理异常，上下文切换昂贵。
HyperEnclave支持三种飞地操作模式： - ①GU-Enclaves 客户机用户模式；VMX non-root, ring-3;
- ② P-Enclaves客户机特权模式或可选客户机用户模式; VMX non-root, ring-0
- ③HU-Enclaves主机用户模式；VMX root, ring-3
P-Encalve
- 访问特权资源
- IDT
- 页表
- 处理特权事件
- 中断
- 异常
HU-Enclave
- 快速世界切换：hypercall (
880 cycles)–>syscall (120 cycles) - 无虚拟化开销
- 适合IO密集和内存密集
世界切换
可信启动
- 由静态不可修改代码CRTM执行测量链的启动，测量存储在TPM PCRs，任何修改都会被反映出来。
- 为了减少PrimaryOS的攻击面，把RustMonitor镜像放在Initramfs，kernel module测量其镜像在early userspace并启动RustMonitor，同时确保RustMonitor加载的软件状态是可信的。
- RustMonitor加载后，RustMonitor设置其运行上下文并准备每个CPU的vCPU，启动的那个normal VM并将primary OS降级为Normal mode，然后返回kernel module，继续Normal mode的启动过程，意识不到RustMonitor的存在
飞地SDK
实现
评估
世界切换性能
P-Enclave use cases: exception handling
真实工作负载
相关工作
- CURE也能支持不同飞地；修改系统总线区支持内存和外设的访问控制；cache划分防止侧信道
- CURE需要改变CPU核以支持eid
- 本文：不需要硬件或固件修改
- 很多工作用虚拟化扩展去支持隔离的执行环境
- TrustVisor
- 只读的PAL页表页去防止内存映射攻击
- PAL注册和状态切换的开销大
- 由于更新OAL页表的访问位和脏位，内存压力大时存在大量NPT违例，导致巨大开销
- Inktag
- hypervisor管理HAP页表，允许不可信OS向hypervisor发送请求以更新HAP页表
- Inktag和TrustVisor容易受到基于页表的攻击
- 本文保护基于页表的攻击
- AWS Nitro Enclaves
- 由主机KVM和Linux组成，主机Linux kernel总是可信的
- TCB大（包括device driver，guest IO，网络和块设备虚拟化）
- 本文：最小化RustMonitor的TCB，执行基本的虚拟化和飞地管理，primary OS只需要在启动过程被信任，RustMonitor启动后primary OS被降级
- Komodo和Keystone
- Komodo（secure user mode）在TrustZone上实现类似SGX的飞地保护模型
- Keystone在RISC-V上实现定制化TEE（U-mode and S-mode）
- 本文：支持灵活的飞地模式(guest ring-3, guest ring-0/ring-3, and host ring-3)
- ARMv9-A architecture的Realm Management Extension (RME)
- monitor（EL3）强制secure、non-secure、Realm的物理内存隔离
- Realm Management Monitor (RMM)执行在EL2 in Realm security state (R-EL2)，通过2级页表隔离Realms
- 与 HyperEnclave 类似，RMM 比典型的hypervisor简单得多，并且依赖于non-secure hypervisor进行设备仿真
- RME需要架构扩展，HyperEnclave不需要；HyperEnclave把信任链和CPU解耦
- TrustVisor
总结
- 开源、兼容SGX的process-based TEE：supports the process-based TEE model, and SGX programs can run on HyperEnclave with little or no code changes.
- 灵活的飞地模式：supports the flexible enclave operation modes to fulfill various enclave workloads
参考文献
[1] https://www.usenix.org/sites/default/files/conference/protected-files/atc22_slides_jia_yuekai.pdf
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，可以在下面评论区评论
