CRONUS

IoT 2周前 admin
39 0 0

CRONUS

本次分享的是由MICRO22的论文《CRONUS: Fault-isolated, Secure and High-performance Heterogeneous Computing for Trusted Execution Environment》,作者是香港大学的Jianyu Jiang等人。本文利用硬件源语(例如Arm TrustZoneRISC-V),为GPUTPUNPU等加速器实现了第一个故障隔离的(fault-isolated),安全隔离的(secure-isolated)异构计算系统。

  • 一、前言

本文总结了三个重要的计算需求:第一,需要在不改动硬件下支持多种加速器,因为修改硬件会丧失兼容性,并且也不容易验证正确性。第二,需要支持多个用户共享一个加速器,这有利于性能。第三、需要支持加速器之间的强隔离,一个原因是支持加速器的平台会产生很多故障,如果一个加速器的故障不隔离就会影响其他加速器;另一个原因是加速器有较好的可编程性,也容易受到代码注入攻击。就现在的设计来看,GravitonHIXHETEECURE(一种支持AXI accelerator的设计)基本都会改硬件,传统的TrustZone设计又不会实现加速器隔离。由此,本文提出了MicroTEE,它实现了上述要求。它把一个单一的enclave(比如TrustZone的安全世界,还有RISC-VM-mode)划分成了多个enclave,把单一的OS划分为多个micro OS(简称为mOS)。每个enclave包含异构计算中的一种计算类型,每个mOS含有一种加速器的运行环境、硬件和drivermOS可以让多个enclave使用, 而MicroTEE也通过enclave之间的远程过程调用(RPC)实现异构计算。而至于如何隔离这些mOSMicroTEE可以使用现有的硬件隔离技术(如Arm SEL2)来隔离,同时创建一个只用于enclave调度和内存管理的mOS来管理这些含有drivermOS,如果一个mOS发生了故障,那么直接重新启动它就好了。

当然,实现起来的一个技术挑战是enclave之间的RPC过于频繁,而激活一个enclave就需要负载不小的上下文切换(Twinvisor证明了这点)。并且攻击者有可能更改调度或者重放enclave来破坏异构计算的完整性,或者通过让一个mOS/enclave运行失败并替换为一个恶意的mOS/enclave,以此泄露数据。为了解决这个问题,本文设计一种新的流式RPCsRPC),以减少上下文切换,并且在RPC过程中抵御扰乱执行顺序和重放攻击。为了解决在产生错误时的攻击,sRPC采取一种proceed-trap的错误恢复方式,它将在错误时继续执行程序,并捕获可能泄露数据的访问。

本文的设计实现主要包括(1)为用户实现了一个验证含有加速器的TEE的协议(2)把加速器(这里使用的是NVIDIA GPUVTA NPUdrivermOS lib整合,以提供基础的功能。至于SEL2部分则由现有的Hafnium hypervisor提供。

  • 二、攻击模型与假设

本文假设非安全世界与S-EL1是不可信的,其他是可信的。S-EL1的每个enclaveS-EL2隔离,互相之间无法破坏。由于每个服务可能使用不同的mOS,因此它们只相信它们自己。本文也假设S-EL1 enclave产生的故障与其他enclave隔离,同时也不会影响系统运行(enclave挂了可以重新启动,但是不确保数据恢复)。

本文主要解决非安全世界的攻击,例如1.尝试调用任意的enclave(执行mECall),或者把来自非安全世界的用户请求转送(mECall)到不正确的enclave2.在安全世界中错误地配置一个加速器,甚至配置一个捏造的加速器。3.扰乱enclave之间的RPC顺序,或者重放RPC4.替换或终止一个mOS/enclave

本文假设了四种硬件源语,即TEE的隔离(例如S-EL2技术),信任根(Root of Trust,用于验证运行在一个正确的TEE中),可信I/O(以确保安全世界与加速器的独立交互,例如使用TrustZone TZPC),enclave之间的共享内存(用于enclave之间的RPC,但是本文对其做了改动,使其更快也更安全)。

  • 三、系统设计

在讲系统设计前,先简单介绍该系统中app的工作流程。首先,app让用户提交一个处理机密数据的manifest,它会创建一个enclave A并初始化+远程验证。在验证后,用户可以提供加密数据给appapp调用RPC,将数据传给enclave Aenclave A再解密并处理数据。如果中间需要其他加速器来处理数据,enclave A会与这些加速器的enclave(假定为enclave B)进行RPC通信,以加速数据处理。

由此,本文在S-EL2 hypervisor下创建多个partition,每个partition运行一个mOS和多个enclave,同时partition与一个设备(CPU或加速器)相挂钩,含有一个驱动。

Enclave中含有一个定义它逻辑的runtime,即用于做什么计算,比如执行动态链接库或者ELF。它相当于一个黑盒,其内部状态(例如内存与GPU状态)是其他enclave不知道的。Enclave定义了一个API表(即mECall表),允许其他enclave通过这些RPC与它交互。

mOS中包含了Enclave ManagerHardware Adaptation LayerHAL)。其中,前者提供基于Diffie-Hellmanenclave验证(这里暂时不提如何远程验证)与初始化enclave,用于在调用者和enclave之间创建可信信道,以及传输加密的数据,也记录enclave使用的资源等功能。后者在Enclave Manager和硬件设备之间提供一系列接口,相当于是一个driver,虚拟化了当前管理的硬件设备。

非安全世界含有一个Enclave Dispatcher主要用于记录“如果App需要某种设备,那么该找哪个enclave”。

因为enclave之间是通过RPC交互的,考虑到同步(synchronize)RPC的办法安全性低且耗时长,本文选择流式RPC的办法。作者观察到加速器执行是顺序并且异步的,那么就让一个CPU enclave连续地发送RPC给加速器enclave,只有当CPU需要数据,或者需要同步时,再发送检查的RPC,并通过TEE之间的共享内存接收数据,注意需要提前做enclave之间的验证和秘钥交互,以及mOSHypervisorSPM)要协助完成内存共享与隔离。

至于对enclave的安全恢复,此处略。


原文始发于微信公众号(COMPASS Lab):CRONUS

版权声明:admin 发表于 2022年11月17日 下午8:23。
转载请注明:CRONUS | CTF导航

相关文章

暂无评论

暂无评论...