【论文】Building GPU TEEs using CPU Secure Enclaves with GEVisor
论文思路整理
背景
已有工作缺陷
- require CPU and/or GPU hardware modification
- rely on untrusted system software
- silicon scaling is slowing
- increases the TCB size significantly
设计的挑战
- Intel SGX was never designed to support I/O operations
- A GPU device driver is needed for GPU computation but can easily bloat up the TCB
- Balance between security guarantees and performance overhead
- Without rigorous security verification, a security solution may introduce a new attack surface
目标
- 可靠 I/O 传输:在飞地的 GPU runtime 和 HyperVisor 联合,确保只有对应的飞地可以访问 GPU I/O 资源。
- 缩小 TCB:将飞地和 GPU 的通信通道和其他系统软件隔离,并在没有驱动参与的情况下完成 GPU 的验证,将 GPU Driver 移除 TCB。通过 dynamic hypervisor measured launch 技术将系统启动引导程序排移除 TCB。
- 低开销:在加密保护和 EPT 保护中抉择。
- 形式化验证:I/O 双重化语义验证
贡献
- HyperVisor 和 CPU enclave 合作,在不需要硬件修改的前提下,实现 GPU 侧 TEE。
- 提出全新的异步 hypercall 减少上下文切换消耗;结合 TPM 和 SGX 远程验证实现了一个线性远程验证协议。
- 进行了形式化验证。
- 评估了 GEVisor 的性能消耗。
Threat Modules
攻击者:OS,GPU Driver,guest VM
信任者:GPU 内存(结构无法被直接读取)、TPM;不考虑 Dos,侧信道攻击。
论文提出了一种新的攻击模型:创建一个新的 GPU 上下文,将其地址映射到受害 GPU 上下文中,偷取数据。
- 攻击面 1:利用 DMA Buffer 在主机和 GPU 随意传输数据。
- 攻击面 2:利用 MMIO 映射在主机和 GPU 随意传输数据。
- 攻击面 3:利用驱动的 API 篡改 GPU 页表,偷取数据。
动机和目标
实现 GPU 侧 TEE 的四种流派:
- 修改 CPU 硬件,使得 CPU TEE 可以直接和 GPU 通信
- 修改 GPU 硬件,强制隔离 GPU 上下文
- 把 HyperVisor 加入 TCB,将 GPU Driver 放入 HyperVisor 中
- 依靠远程验证减小 TCB
五个目标:
- Complete Mediation:覆盖所有 GPU 通道的访问控制,监控所有 MMIO/DMA 访问,完全隔离不同 GPU 上下文。
- Tamperproofness:所有 TCB 以外的部件都不能篡改 GPU TEE。
- Verifiability:TCB 足够小,支持形式化验证。
- Deployability:无需硬件修改,可以部署到现成商用服务器。
- Low Overhead:低开销。
系统架构设计
GEVisor 是一个轻量级 HyperVisor,和 SGX enclave 合作实现 GPU TEE,也即上文提到的五个目标。GPU enclave 由两部分组成:UNTRUSTED RUNTIME 以及 ENCLAVE GPU RUNTIME
UNTRUSTED RUNTIME
- 负责和 GPU Driver 交互,创建 GPU 上下文
- 将 DMA 和 MMIO 区域映射到用户进程的虚拟地址空间中
- 不可信,可能受到攻击者的攻击
ENCLAVE GPU RUNTIME
- 和 GPU 驱动交互,将数据从 enclave 复制到 DMA/MMIO Buffer 中,完成和 GPU 的通信
- GEVisor 作为一个轻量级的 HyperVisor,和 ENCLAVE GPU RUNTIME 协作保护 DMA/MMIO Buffer 不受攻击
- ENCLAVE GPU RUNTIME 和 GEVisor 的通信通过 communication channel 完成,CC 是 enclave 和 GEVisor 共享的一段内存空间
- ENCLAVE GPU RUNTIME 将访问请求控制信息通过 CC 传递给 GEVisor
使用 enclave 构建 GPU TEE 带来的新攻击面
其他核心上的进程访问 enclave 数据 =>
- 记录 enclave ID,只有持有对应 ID 的进程才能访问 enclave 的数据,只有持有对应 ID 的 enclave 才能访问对应的 GPU 上下文和 DMX/MMIO Buffer
- 只有持有对应 ID 的 enclave 才能访问 GPU 对应内核的页表
- GEVisor 保存 enclave ID,GPU context ID,Buffer 地址信息
- 加强 ECALL/OCALL 退出点的管理
GEVISOR
GEVISOR 由三部分组成:memory contraction,IO protection,MRTable
GEVISOR 启动后,保留一部分 CPU 核心在 VMX-root 模式,这部分核心不需要进行 VMX 切换,不需要运行 enclave,只需要处理 GPU I/O 保护任务。通过这种设计,GEVISOR 能够实现 enclave 和 GPU I/O 访问控制的并行运行,也即 Asynchronous Hypercall
只配置三个区域的 EPT trapping:MMIO/DMA 区域、enclave 区域、GPU CC 区域。访问其他内存区域时不触发 EPT trapping,减少性能开销
Asynchronous Hypercall Offloading
当 Guest OS 发出 HyperCall 请求 HyperVisor 处理某些任务时,会停止执行并等待 HyperVisor 处理完毕。而异步 HyperCall 使得 Guest OS 在发出 HyperCall 请求后可以继续执行,无需等待。核心原因是针对 I/O 的 HyperCall 参数少而且没有返回值。
Guest OS 将 HyperCall 请求发送至 Ring Buffer,其中 HyperCal 请求被修改为统一的格式(HyperCall ID, Status, num of para, para1, para2, para3)。Ring Buffer 中包含一个 status 标志位,Free or Busy,Guest OS 向 free 的栏目写入 HyperCall 参数,并将 status 修改成 busy;GEVisor 执行结束后将 status 恢复成 free。
软件 IPI handler 负责管理 remote core 并处理 HyperCall。
Communication Channel Protection
CC 是 enclave 发送 HyperCall 到 GEVisor 的通道,是固定的一段内存区域。GEVisor 将 CC 对应的内存区域设置为 EPT trap 模式,也即访问这部分区域将触发 VMExit 并交给 GEVisor 处理。
一般使用 CR3 寄存器存放当前进程的页表基地址,但是 CR3 无法区分来自普通进程的访问和 enclave 的访问。故 GEVisor 还会拦截 enclave 指令,在 EINIT, EEXIT, EREMOVE 命令时撤销对 CC 的访问权限,只有当 enclave 的状态是正在执行时(EENTER, ERESUME)才重新授权。
Linear Remote Attestation Protocol
一种线性远程验证协议,用于验证 Enclave 和 GEVisor 的可信性
GPU PROTECTION
Unified GPU I/O Protection
GEVisor 可以保护 GPU 侧的 DMA Buffer 和 Command Buffer 不受攻击者的访问
GEVisor 使用 MRtable 来存储每个 enclave 拥有的 MMIO/DMA 的 gva -> gpa 的映射,当 enclave 执行的时候,对于 GPU I/O 页面的访问,GEVisor 可以使用 EPT 或 异步 HyperCall 来控制。
GEVisor 移除了 MRtable 中每个页面的读写权限,任何访问请求来源都会被捕获并经过验证:进程包含 enclave ID && VA 对应 && PA 对应
Asynchronous Hypercall
正常情况:EPT 中设置 DMA 页面为不可访问,enclave 访问时触发 EPT trapping。GEVisor 允许 enclave 通过 HyperCall 主动发起 MMIO/DMA 访问请求,维护一个 access-list 存储所有的 I/O 访问请求,将请求中的地址参数,enclave ID 等和 MRtable 中的项进行比较。
GEVisor 需要确保在 enclave 因为各种原因停止运行时,需要将敏感区域立即保护起来,防止同一个 CPU 核心非法访问。
在存在其他非法设备时,OS 可能将其他设备的 MMIO/DMA 区域映射到 GPU 对应位置,可以使用 IOMMU 来避免该攻击面。通过配置 VMCS 来截获全部的 IN/OUT 指令,对于非法设备的 MMIO 访问,GEVisor 负责检查 PCI 配置空间和 BAR 寄存器来验证其合法性。
GPU Context Isolation
GEVisor 维护了一种数据结构 OM,每一行存储 上下文 ID,enclave ID,物理地址,虚拟地址,大小,其中物理地址/虚拟地址是 GPU 侧的。
创建上下文时会通知 GEVisor 创建对应的 OM 项,当驱动试图访问 OM 中的页面时,GEVisor 会通过 EPT 拦截并根据 OM 检查权限。