CRONUS

IoT 1年前 (2022) admin

497 0 0

CRONUS

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

一、前言

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

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

本文的设计实现主要包括（1）为用户实现了一个验证含有加速器的TEE的协议（2）把加速器（这里使用的是NVIDIA GPU和VTA NPU）driver与mOS lib整合，以提供基础的功能。至于SEL2部分则由现有的Hafnium hypervisor提供。

二、攻击模型与假设

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

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

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

三、系统设计

在讲系统设计前，先简单介绍该系统中app的工作流程。首先，app让用户提交一个处理机密数据的manifest，它会创建一个enclave A并初始化+远程验证。在验证后，用户可以提供加密数据给app，app调用RPC，将数据传给enclave A，enclave 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 Manager与Hardware Adaptation Layer（HAL）。其中，前者提供基于Diffie-Hellman的enclave验证（这里暂时不提如何远程验证）与初始化enclave，用于在调用者和enclave之间创建可信信道，以及传输加密的数据，也记录enclave使用的资源等功能。后者在Enclave Manager和硬件设备之间提供一系列接口，相当于是一个driver，虚拟化了当前管理的硬件设备。

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

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