VIII. 评估

SCL利用DataCapsules作为数据表示来支持enclave间通信。为了量化其优势和局限性，我们提出以下问题：(1) SCL作为KVS的性能如何(§VIII-B)？(2) 循环缓冲区(§VIII-D)和复制(§VIII-C)如何影响开销？(3) 安全启动PSL任务需要多长时间？(§VIII-E) (4) SCL在enclave内运行分布式应用需要付出多少代价？(§VIII-F)

A. 实验设置

我们在十五台Intel NUC 7PJYH上评估PSL，配备Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz，具有4个物理核心（4个逻辑线程）。处理器具有96K L1数据缓存、4MiB L2缓存和16GB内存。机器使用Ubuntu 18.04.5 LTS 64位，Linux内核5.4.0-1048-azure。我们运行Asylo 0.6.2版本。我们报告进行10次实验的平均值。每台NUC默认运行两个PSL线程。

B. SCL端到端基准测试

基准测试设计：SCL的端到端评估从工作器向用户发送第一个确认开始，到客户端从工作器接收到最后一个请求的响应结束。我们使用YCSB工作负载生成器生成的工作负载来评估性能。由于get和put协议之间的差异，我们专注于只读和只写工作负载。所有工作负载都符合zipfian分布，其中键以非均匀频率被访问。对于每个get，我们评估从lambda的本地memtable获取(get(cached))和从CapsuleDB获取数据(get(uncached))的性能。每个get请求都是同步的，只有在收到前一个get请求的值后才会发送下一个请求。

整体性能：图9显示了端到端YCSB基准测试的吞吐量。put的聚合吞吐量。get(CapsuleDB)吞吐量随着lambda数量的增加而趋于平缓，因为我们运行单个CapsuleDB实例处理所有查询，随着发出get(CapsuleDB)的lambda数量增加，这成为瓶颈。

图9：PSL在YCSB基准测试的只写和只读工作负载上的聚合吞吐量。get根据是否在memtable中缓存（左）或lambda需要查询CapsuleDB（右）进行区分。

图10：显示有复制与无复制的SCL端到端只写基准测试的折线图。吞吐量数字采用对数刻度。

C. 启用复制的端到端基准测试

基准测试设计：启用复制的端到端评估测量具有持久性的SCL层的性能。特别地，它包括工作器将每个写入发送到DataCapsule副本的开销，多数DataCapsule副本接收数据并将其持久化到磁盘，然后确认工作器。我们使用YCSB工作负载生成器生成的工作负载来评估性能。由于复制仅涉及写操作，我们评估只写工作负载。工作负载涉及zipfian分布，键以非均匀频率被访问。

整体性能：图10说明了DataCapsule后端的性能。它显示启用复制的SCL在9个工作器后达到瓶颈，而无持久性的SCL继续扩展。性能下降和瓶颈的原因有几个：1) 磁盘操作本质较慢；2) 复制系统领导节点收集DataCapsule副本的确认并将聚合确认发送回工作器的负担较重。我们旨在通过减轻复制领导节点的工作负载来改进启用复制的SCL。

D. 循环缓冲区微基准测试

基准测试设计：循环缓冲区提供高效的应用程序-enclave通信。我们比较循环缓冲区与SGX SDK基线和最先进的HotCall的性能。我们基于enclave与应用程序之间双向通信所需的时钟周期数来评估它们。

整体性能：如表I所示，基线SGX SDK从应用程序到enclave产生超过20,000个时钟周期的显著开销，从enclave到应用程序产生超过8,600个时钟周期。对于两个方向，HotCall能够将开销减少到一千个时钟周期以下。我们的循环缓冲区进一步减少了开销。我们的解决方案从应用程序到enclave仅需461.1个时钟周期，反之需525.54个时钟周期。与最先进的HotCall相比，我们的解决方案分别提供了103%和44%的改进。

表I：循环缓冲区微基准测试我们评估enclave和应用程序之间双向通信所需的时钟周期数。

图11：Paranoid Stateful Lambda启动过程的延迟分解。粗线表示lambda启动过程的关键路径。在认证工作器中运行代码的总启动时间小于0.61秒。

E. Lambda启动时间

基准测试设计：我们通过在工作器和FaaS领导节点在SGXv2硬件模式下运行来评估PSL的启动过程，其中工作器lambda、FaaS领导节点和用户位于不同的物理Intel NUC机器上。对于每个NUC，它在硬件模式下运行Asylo AGE，使用Intel签名的PCE，帮助enclave生成认证断言。我们假设机器已经拉取了预构建的lambda运行时二进制文件并执行运行时。在我们的实验设置中，冷启动引导过程平均持续42秒。

Lambda启动分解：图11显示了启动过程的延迟分解。用户联系调度程序以及调度程序找到加密任务并转发给潜在工作器需要0.30秒。然后工作器将相关运行时和数据加载到enclave，这需要0.16秒。我们将工作器加载时间与认证并行化。用户远程认证FaaS领导节点以验证FaaS领导节点正在SGX enclave中运行认证代码。在工作器的enclave文件加载后，FaaS领导节点远程认证工作器enclave平均需要0.103秒。我们注意到这种认证延迟主要由grpc请求的网络延迟和工作器AGE的本地认证断言生成时间构成，因此当多个工作器同时启动时，不会导致FaaS领导节点的可扩展性问题。

表II：运动规划基准测试

F. 案例研究：雾机器人运动规划器

我们实验了一个基于采样的运动规划器，该规划器被并行化以在多个并发无服务器进程上运行，MPLambda [23]，并修改它以使用SCL。大部分移植工作是将MPLambda的构建系统集成到Asylo中。修改大约100行代码。MPLambda使用的许多系统调用由Asylo代理。

使用带有SCL的MPLambda，我们计算了一个运动规划，运行一个fetch场景，其中Fetch移动操作机器人[17]清理桌子。我们测量规划器找到第一个解的中位挂钟时间。我们还测量规划器返回的最低成本路径的中位平均路径成本每时间。这捕获了规划器计算最佳路径的效率。由于规划器使用随机采样，我们使用不同的种子多次运行相同的计算。与之前的实验一样，我们在Intel NUC 7PJYH上运行此测试，配备Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz，具有4个物理核心（4个逻辑线程）。我们为规划器计算路径设置600秒的超时。

我们运行最多8个规划器，在单独的Intel NUC上使用SCL运行，并将其与不使用SCL运行MPLambda进行比较。我们观察到随着规划器数量的扩展，性能有所提高。每个规划器运行计算密集型工作负载，PSL引入了多个线程（即加密参与者、zmq客户端、OCALL/ECALL处理程序），这些线程从规划器线程中占用CPU时间。此外，MPLambda规划器使用快速探索随机树(RRT*) [24]算法，通过从搜索空间随机生成样本来搜索路径，检查样本是否可行探索，并将样本添加到构建的树数据结构中。树数据结构可能变得很大并占用大量内存。SGX中的内存是有限资源，增加的内存压力导致EPC中更多未命中，并需要频繁地在enclave内外进行分页。有工作通过限制树数据结构的内存来限制RRT*的内存使用，我们可以在未来的工作中采用。[2]。