Orca: FSS-based Secure Training and Inference with GPUs

1.Abstract

端到端系统ORCA：

• 加速基于 FSS 的使用 GPU 的 2PC 协议的计算。
• 新的基于 FSS 的 2PC 协议
• 提供了第一个用于随机截断的安全协议，并在此基础上提供了对具有端到端安全性的训练的首次评估。
• ORCA 在 CIFAR-10 上具有 4% 更高的准确性，98 倍更少的通信，并且速度提高了 26 倍。
• 对于安全的 ImageNet 推断，ORCA 实现了 VGG-16 和 ResNet-50 的亚秒延迟，并且比最先进技术快 8-103 倍。

2.Accelerating FSS on a GPU

2.1 Accelerating FSS-based compute on GPU

2.1.1 Faster AES computation (AES)

• AES 加密： AES 需要反复查找预先计算的查找表（lookup table）

• 常量缓存（constant cache）： GPU 中的常量缓存用于存储只读数据，在每个流处理器（SM）中都有一份副本。访问常量缓存通常很快，适合并行计算。

• 访问模式要求： 常量缓存的性能依赖于 GPU 线程的访问模式。如果所有线程在同一时间访问同一个地址，性能非常高。如果不同线程访问不同地址，访问会被序列化，导致性能下降，甚至导致计算停滞（stall）。

问题分析：

• 在 AES 加密过程中，不同的 GPU 线程会访问查找表中的不同索引。
• 由于查找表存储在常量缓存中，当不同线程访问不同地址时，这些访问会被序列化。
• 这种序列化会导致访问延迟（stall），从而影响整体性能。

解决方案:

1.查找表复制策略：

• 每个 warp 复制查找表： 每个 SM（流处理器）中的 warp（通常为 32 个线程）都拥有一份查找表的副本。这意味着在每个 SM 中，共有 32 份查找表副本。
• 这种策略基于先前的研究【61】，目的是减少不同线程访问同一份查找表时的冲突，从而减小序列化访问带来的性能损失。

2.将查找表放置在共享内存中：

• 共享内存（scratchpad memory）： 共享内存是每个 SM 上的高速缓存，用于存储线程块内共享的数据。
• 共享内存的分块（banking）：共享内存分为多个内存银行（banks），每个银行可以独立处理一个内存请求。这样设计使得不同银行的数据可以并行访问，从而避免了访问冲突和停滞。

3.查找表副本放置在不同的内存银行中：

• 避免访问冲突： 通过将查找表副本放在共享内存的不同银行中，不同线程可以同时访问不同银行的数据，避免了因访问相同内存位置而导致的序列化访问问题。
• 提高访问效率： 由于共享内存银行可以并行访问，查找表放置在不同银行后，线程访问查找表的速度显著提高，减少了计算停滞。

2.1.2 Optimized data layout for cache locality (LAYOUT)

背景：

• DCF计算： 计算 DCF 需要评估者执行 n 个链式伪随机生成器（PRG），每个 PRG 调用两次 AES。评估者在调用第 个 PRG 之前，需要稍微修改第 个 PRG 的输出，并使用一个修正词（correction word，CWi）进行调整。
• 修正词的数量和存储： 每个 DCF 键有 n 个修正词。这些修正词在内存中的布局会影响性能。

并行化实现

1.CPU上的并行实现：

• 在 CPU 上，每个线程独立地在一个 CPU 核心上计算 DCF。将用于 DCF 计算的 n 个修正词在内存中连续布局，可以更好地利用缓存局部性，从而提高缓存命中率。

2.GPU上的并行实现：

• 在 GPU 上每个线程计算 DCF 时同步进行。Warp 中的所有线程必须在第 𝑘−1 个 PRG 计算完成后，才能继续第 𝑘 个 PRG 计算。

内存布局优化：

• 传统布局的缺点： 如果像在 CPU 实现中一样，将 n 个修正词在内存中连续布局，会导致缓存命中率低下。这是因为每个线程在不同的时间访问不同的修正词，导致缓存局部性差。
• 优化布局的策略： 为了提高 GPU 上的缓存命中率，应第 k 轮 PRG 计算的所有修正词在内存中连续放置，第 k+1 轮 PRG 计算的修正词紧接其后，以此类推。

2.1.3 Optimizing memory footprint (MEM)

背景和问题：

• FSS 协议：FSS 协议降低了通信开销，但要求较大的密钥大小。
• 存储和读取：密钥通常存储在 SSD 上，并在在线计算期间读入内存。读取大密钥会非常慢，尤其是从 SSD 读取。
• 数据传输：大密钥不仅增加了通过 PCIe 总线在 CPU 和 GPU 之间传输的数据量，还占用了有限的 GPU 内存。

解决方案：

1.减少密钥大小：

• 使用小负载的 DCF： 例如，使用 1-bit 而不是 64-bit 的负载，并尽可能使用 40-bit 而不是 64-bit 的输入进行比较。
• 优势： 减少密钥大小降低了 CPU 和 GPU 之间的数据移动量，并减小了 GPU 内存占用。

2.避免内存膨胀：

• 问题： 如果简单地将 1-bit 输出存储到标准数据类型（如字节），会导致 8 倍的内存膨胀。
• 解决方案： 在 ORCA 中，warp 中的 32 个线程以锁步方式将各自的 1-bit DCF 输出写入一个 32-bit 整数中。

3.避免使用锁：

• 问题： 在 GPU 上使用锁非常慢。
• 解决方案： 利用 CUDA 的 warp 同步原语，确保 warp 中的每个线程在写入时不会相互干扰。

结果和性能提升:

• 通过这种优化，执行一千万个 DCF 的时间减少到 523 毫秒，比简单实现提高了 27%。总体上，比原始的简单实现提高了 6.3 倍

2.2 Reducing time to read FSS keys

FSS 协议的优势：

• 主要优势是减少各方之间的通信量。
• 需要在进行在线计算时读取大量预生成的密钥。

性能瓶颈：

• 尽管通过优化策略加速了 GPU 上的计算，读取 FSS 密钥的时间（从 SSD 到 GPU 内存）成为新的瓶颈。

2.2.1 Bypassing OS page cache

背景：

• 默认情况下，操作系统将文件内容缓存到CPU的DRAM上，希望随着时间的推移，文件的数据将被反复访问。

问题：

• 页面缓存会在访问文件内容的关键路径上增加开销

原因：

• FSS密钥只能使用一次，没有再利用
• 包含FSS密钥的文件不会受益于页面缓存，但支付开销

2.2.2 Overlapping key read with computation

减少键读取时间的影响：

• 将第i次训练迭代的计算与第(i + 1)次迭代的键读取计算重叠。
• 确保整个键读取时间都不在关键路径上。

2.2.3 New cryptographic technique to limit key size

问题：

• 即使经过上述优化，对于较大的网络，从SSD读取密钥的时间也会超过GPU的计算时间

原因 ：

• 当计算在GPU上像在ORCA中那样得到很好的加速时，键读取时间才会成为瓶颈
• 其它情况并非如此

解决方案： 构建了新的FSS协议

• 减少流行的非线性(如ReLU和maxpool)中的密钥大小
• 减少在线通信
• 与量化训练中的截断相结合

3.Evaluation