本次分享的文章发表在USENIX Security’21，作者是达姆城工业大学的Raad Bahmani等人。本文提出一种具有弹性的、可定制的enclave设计，用于满足包括安全机器学习（需要与外设创建可信信道）在内的多种需求，同时还能抵御侧信道攻击。该设计在RISCV上实现,引入15%左右的性能负担。
一、攻击模型
本文设想的攻击者主要活动在OS，也会向hypervisor植入代码，但是还没破坏一块用于配置硬件源语的TCB（类似于Arm的ATF）。攻击者可能不会修改固件代码，但是仍然可能使用内存破坏（memory corruption）产生的漏洞，通过攻击TCB和enclave来获取数据。攻击者也会使用外设来进行DMA攻击。
二、设计
2.1 前言
本文指出当前的enclave设计基本是“one-size-fits-all”的，总之就仅提供一种enclave，毫无feature。此外，考虑到现在机器学习很火，那enclave也要与GPU等加速器外设实现安全信道，但是SGX没考虑解决这个事情，其他设计也用的入侵式的硬件修改来实现安全信道。最后是侧信道攻击，现在的设计要么根本不考虑它，要么可能会非常影响OS的功能。
为解决这个事情，本文将提出CURE，它首先提供多种多样的enclave。此外，CURE也应该将外设绑定到独占的enclave，以实现独占性和隔离。最后，CURE会提供侧信道保护，包括对cache的细粒度保护。
总的来讲，有四个安全性目标：（1）保护enclave（2）只能使用软件可以config的硬件源语（3）TCB要小（4）抵抗侧信道攻击；以及有五个功能性目标：（1）动态enclave大小 （2） enclave与外设绑定（3）最小硬件修改（4）低overhead（5）针对cache侧信道攻击有动态的保护机制。
2.1 不同的enclave
CURE提供了一个完整而详细的enclave管理机制，包括安装、创建、执行、销毁enclave，此处不再细讲。对于各种enclave，这里简单说三种。
一个是用户空间enclave，它依赖OS提供内存管理、中断处理、系统调用等功能。但是它要确保数据安全性，比如将一些OS管理的页表移动到enclave内存里来抵御OS的攻击。这种enclave因为不能含有OS层的代码，所以功能也有限（比如无法控制driver），只能做一些简单的操作（例如一次性密码生成），其二进制文件大小也有限；
较大一点的是内核空间enclave，它需要在运行环境里独立实现内存管理等的OS服务，或者实现对driver的保护。类似于用户空间enclave，内核空间enclave也要保护自己的页表来阻止不可信的hypervisor对他的访问（这里可能RISC-V没有像Arm那样的二级映射，所以保护起来容易一点）。
最后是子空间（sub-space）enclave，它用于隔离一些CURE的TCB，可以把它看做为ATF一样的东西，但是ATF是完全占用EL3，这个是部分占用。
2.2 enclave访问控制
CURE给每个enclave一个ID。这个ID信息保存在一个寄存器里，当enclave创建时就往该寄存器写入对应ID。ID数量可以有限制，用于限制能有多少并行enclave。而传播ID信息到整个系统，可以利用TileLink等的协议来确保传输的安全性。
2.3在主线（bus）上的访问控制
CURE需要在主线上限制外设等的访问（有点类似于Arm TZASC），这种设计是中心式的、嵌套式的，以减小性能负担。具体来说，当CPU想访问内存时，CURE将验证enclave ID信号（这种信号将传导到主线上的控制单元）来确保CPU能否访问。而对于CPU访问外设，CURE主要通过控制MMIO，并且兼容以上对CPU访问的控制方法来实现。对于DMA访问内存，CURE也把它包装到一个enclave里，并且规定该enclave能访问多少内存资源，最后通过类似控制CPU访问内存的方式来控制DMA访问内存。
2.4 针对cache的防御
CURE需要在enclave切换时清L1 cache，但是对于一些核之间共享层的cache仍然不够。所以CURE提出一种对每个enclave的cache划分（虽然会引入性能负担）。具体来说，每个cache way会划给特定的enclave，并且也会限制MMIO式的访问。而对于enclave和OS有共享内存的情况，CURE就需要在enclave切到OS时清空对应cache。
原文始发于微信公众号（COMPASS Lab）：论文分享：《CURE：可自定义的、具有弹性的enclave》
