【架构论文】SCALE: Secure and Scalable Cache Partitioning（2023 HOST）

SCALE: Secure and Scalable Cache Partitioning

摘要

LLC可以提高性能，但是会引入安全漏洞，缓存分配的可预测变化可以充当侧信道，提出了一种安全的缓存分配策略，保护缓存免受基于时间的侧信道攻击。SCALE使用随机性实现动态可扩展的分区，添加噪音防止对手观察到分配中的可预测变化，利用差分隐私，并证明SCALE可以提供可量化和信息理论的安全保证。SCALE在具有多编程工作负载的16核平铺芯片多处理器上优于最先进的安全缓存解决方案，并将性能提高39%。

介绍

静态分区不能满足应用程序 不断变化的需求，性能低于动态分区；
动态分区方案包括：确定分区分配策略，以最大化聚合指标；维护分区的强制机制。
之前的工作集中于执行机制，不能满足理想执行机制的要求：支持细粒度分区、可扩展性、位置感知分区，以在安全的同时减少片上访问延迟。

动态安全的确定分配具有挑战性，分配需要有关应用程序缓存需求的信息，有两种保护分配的方式：

• SecDCP ：允许从公共层的单向泄露，只考虑公共应用程序的缓存需求来确定分配。
• OPTIMUS：在执行开始时，执行一次分配来限制信息泄露。
  评估表明，这两种建议没有提供更好的改进，现有的分配策略和实现机制不支持安全可伸缩的缓存分区。
  本文提出了新颖的动态缓存分区解决方案SCALE，保护LLC免受基于时序的侧信道攻击，具有可伸缩性和位置感知性。
  SCALE的缓存分配策略利用随机性，向确定性计算的缓存分配决策添加噪声来实现设计目标。本文也是第一篇用DP来防止缓存侧信道攻击的文章。噪声可以防止基于冲突的攻击，但还可以观察到一些攻击可以利用的模式，为了解决这个问题，引入了两个额外的随机化级别。

安全分析表示，SCALE为配置范围的分配变化提供强大可量化的信息理论安全保障，同时为较大的变化提供了较弱的保证和较低的信道带宽。此外，SCALE还支持安全和非安全应用程序的混合，可以抵抗分配策略侧信道攻击，同时保留UCP等非安全分配策略的大部分性能优势。

SCALE提出的安全执行机制建立在DELTA执行机制上。DELTA 结合了 bank 和 way 分区，以支持细粒度分区和位置感知数据映射。SCALE的adaptatipns可实现安全实施，减少处理共享数据相关的开销。SCALE的实施机制支持对缓存容量进行安全、细粒度和位置感知的分区。为了证明 SCALEs 分配策略对商用设计的适用性，我们结合一种与英特尔 CAT 安全版本相当的强制机制对其进行了评估。

贡献如下：

• 演示了对缓存分配策略侧信道的基于冲突和占用的攻击，并提出了一个框架，该框架受到先前工作的启发，用于表征信道带宽和错误率。
• 提出了 SCALE，这是一种用于安全且可扩展的动态缓存分区的整体解决方案。SCALEs 分配策略以一种新颖的方式利用随机性来防御对缓存分配策略侧信道的攻击。
• 基于DP的安全分析表明，SCALE提供了可量化和信息论的安全保障。SCALE 在 16 核 CMP 上优于最先进的安全缓存分区解决方案，与未分区的共享 LLC 相比，性能平均提高了 39% 和 14%。

背景和动机

A . 缓存策略

我们使用 UCP，一个动态缓存分区解决方案来说明缓存分配策略的操作。
UCP 中的分配策略包括两个步骤。

第一步，估计每个应用程序的效用，这有助于确定每个应用程序将从额外容量中受益的程度。UCP 使用实用程序监视器 （UMON） 来估计每个应用程序不同缓存大小的实用程序。
第二步，比较不同缓存大小下每个应用程序的估计效用，并使用 Lookahead 算法计算分配。简而言之，Lookahead 比较应用程序的效用值，识别具有最高效用的应用程序，并分配最大化效用的容量。

在预设时间（重新配置周期）后重复这两个步骤，并根据前一个周期收集的统计数据确定分配。在商用系统中，效用是使用性能计数器或使用英特尔的缓存监控技术来估算的。请注意，效用估计和容量分配是可预测和确定的，即对于给定输入，效用和分配始终保持不变。

B. 缓存分配策略侧信道

典型的侧信道攻击包括三个步骤：干扰、等待和分析。缓存分配策略可以充当侧信道，并将信息从受害者泄露给对手。

基于冲突的攻击：我们说明了对缓存分配策略侧信道的基于冲突的攻击，以及 GnuPG v 1.4.13 中 RSA 和 EIGamal 解密中使用的数据相关平方乘幂算法。在算法中，指数位的不同值会导致不同的代码执行路径。具体来说，指数中的“1”产生平方约简乘约步长，而“0”导致平方约简步长，见图1a。为了便于说明，我们假设受害者和对手共享一个 4 路缓存，如图 1c 所示。在干扰步骤中，攻击者将分配策略设置为两种方式的均等分配，以确保效用从执行指数中位 ’ 1 ’ 的平方乘幂算法将导致分配增加，而执行相同 bit ’ 0’ 的相同算法将导致分配不会改变。接下来，受害者执行算法并更改缓存分配，以防它在指数中遇到“1”代码执行路径的差异反映在效用估计上（见图1b），并导致可预测的分配变化（见图1c），由于分配策略的确定性。最后，通过访问自己分区中的数据并测量时序，攻击者可以确定自己的分配，推断受害者的分配，并得出结论，受害者访问的位是“1”还是“0”。以这种方式泄漏指数位会导致 RSA 和 Elgamal 解密中私钥的恢复 。我们省略了放大/同步细节，这些细节可以像在其他侧信道攻击中一样处理。一个简单的放大步骤是确保指数计算中的效用变化将导致分配变化。这可以通过操纵受害者或对手的工作集大小来确保，例如通过访问适当大小的数据集。

非安全和确定性的分配策略可能会受到攻击和操纵，以便提取有关共同运行的受害者进程的信息，即使存在安全的强制机制也是如此。粗粒度的强制机制，如英特尔 CAT，不为缓存分配侧信道提供保护。上面的示例展示了如何通过缓存分配和揭示机密来观察微小且可预测的实用程序更改。

基于占用的攻击：除了基于冲突的攻击之外，观察缓存分配的变化还可以发起基于占用的攻击并泄露敏感信息，类似于Shusterman等的攻击。前面的示例说明了这一点。图 1d 显示了使用单个指数位序列在算法的两次不同运行中如何更改对手的缓存分配。在这里，攻击者在等待受害者传输每个连续的位之前，会干扰并将分配重置为相等的分区。结果表明，由于缓存分配策略的确定性，使用相同指数位序列的不同执行提供相同的缓存分配序列。监控这些信息可以让对手了解受害者分配的指纹。

C. 威胁模型

威胁模型假设受害者和对手代码在不同的进程上运行。
L1 和 L2 缓存通常是私有的，我们专注于 LLC 上的缓存定时攻击（即基于冲突的、基于共享内存的、基于占用的）。
假设受害者总是被归类为具有安全要求的进程，而对手可以被归类为安全或非安全。
认为属于同一进程的线程（多线程应用程序）不能同时充当对手和受害者。
假设攻击者可以对自己的缓存访问进行计时。
威胁模型排除了依赖于 LLC 端口或 NoC、带宽中的争用的攻击，以及对核心中的分支数据结构、TLB 或共享功能单元等的攻击。这些攻击还有其他防御措施，可以与我们的防御措施相结合。
如果 L1 和 L2 在不信任的超线程之间共享，我们假设私有缓存的分区方式相等，并在上下文切换上使用刷新。

SCALE：安全分区

A. 安全分配策略

我们重新设计了分配策略，以提供安全保证，同时提供动态缓存分区的性能优势。关键思想是通过向分配添加噪声来确保分配策略的安全。这可以防止对缓存分配策略侧信道的基于冲突和占用的攻击。

图 2 概述了 SCALEs 的分配策略。我们假设系统上运行的所有应用程序都是安全的，SCALE 中的分配策略使用实用程序监视器来估计实用程序，并使用 Lookahead 算法来计算确定性的非安全分配。SCALE使用Lookahead算法利用当前分配和为即将到来的重新配置期计算的新分配作为输入。然后，它应用不同的防御机制，将随机性引入分配中。在每个缓存重新配置期间重复该过程。

第一种防御措施添加了使用拉普拉斯分布生成的随机噪声，以更新由非安全策略计算的分配。噪声提供防止信息泄露的安全保障，其中仅对受保护范围提供强保障。保护范围和增加的噪声量可根据安全要求进行配置，
第二道防线随机化分配更改率，这决定了在单个重新配置期间分配可以更改的程度。随机化变化率会导致分配的变化在几个重新配置期间逐渐发生。此外，在每个重新配置期间，分配更改将有所不同。
第三道防线将重配置周期的长度随机化，从而随机化分配更改的时间，同时也降低了信道带宽。

1）使用拉普拉斯噪声
使用拉普拉斯分布产生的噪声添加到使用Lookahead算法计算的缓存分配中。其中噪声是在函数 generateRandomNoise（） 中计算的（第 4 行）。此函数的输出是要添加到电流分配中或从电流分配中减去的噪声量。函数 randRound（） 选择以相等的概率向上或向下舍入噪声值，这会导致更好的安全保证。

由于噪声是单独添加到为每个应用程序计算的分配中，因此算法可能会达到调整后的分配总和超过总可用缓存容量的状态。为了解决这种情况，我们调整了容量，如第 7 行所示。函数 adjustCapacity（） 将从随机选择的应用程序中减去/添加一种方式，直到分配与完整缓存容量匹配（第 10-22 行），同时确保每个应用程序获得最小 minWay 分配。
使用一个示例，其中有两个应用程序 A 和 B，它们共享 16 way的缓存。首先，Lookahead 算法将确定最佳分配（A 和 B 的4 way和 12 way）。接下来，使用拉普拉斯为每个应用生成噪声。为 A 和 B 生成的噪声分别为 -1 和 +3，因此最终为 A 分配了 3 个通道，为 B 分配了 15 个通道。分配的容量之和为 18 way，这超过了缓存的总可用容量。adjustCapacity（）然后通过（随机）选择 B 和 A 来减少分配，从而为 A 分配 2 way，为 B 分配 14way。

2）随机变化率
随机更改率 （ChangeRate） 限制了在单个重新配置周期内每个应用程序的分配可以更改的程度，并使新分配依赖于以前的分配：

该算法将当前分配和新计算的即将到来的重配置期的分配作为输入，从而创建一个反馈循环。该算法通过计算当前分配和新分配之间的差异（第 4 行）并将其用作 generateRandomChangeRate（）（第 5 行）的输入来限制变化的程度。此函数的输出是从均匀随机分布中提取的允许变化量。通过此过程确定的更改将添加到当前分配中，以获得即将到来的期间的随机分配（第 6 行）。为了确保分配整个容量，我们调用了算法 1 中所示的 adjustCapacity（）（第 9 行）。

3）随机重配置周期
防御 RandRecon在每个事件后为下一个重配置事件随机选择一个重配置周期。这将使可观察到分配更改的时间随机化。此外，使用更长的重新配置周期会降低通道带宽。

4） 综合防御

5）可配置性
SCALE可根据系统管理员确定的安全要求进行配置。对于每个安全应用程序，可以单独配置需要保护的分配更改粒度，即受保护范围以及安全级别。噪声参数 capacitySetting和ε分别用于指定受保护范围和所需的安全保证。使用这些参数，将确定噪声的幅度，即比例因子 b。capacitySetting可以设置为 32KB（1 路）和 512KB（16 路）之间的任何值，步长为 32KB。SCALE为保护范围内的分配变更提供强大的安全保障，对较大的变更提供较弱的安全保障和降低的信道带宽。只需要较小保护粒度或较弱安全保证的应用程序，使用 capacitySetting和ε，可以期待更好的性能。对于 ChangeRate，我们将更改率间隔限制在 10% 到 25% 之间。RandRecon使用设置 reconfig period interval 进行配置。选择设置对性能的影响以 V-C 显示，而安全影响以 IV-B 显示。对于具有严格安全要求的应用程序，如果有关工作集大小的任何信息都不能泄露，则可以使用相等的静态分区(ε=0).

6） 安全和非安全应用程序
SCALE可以同时运行应用程序，无论是否具有任何安全要求。在这里，应用程序分为安全应用程序和非安全应用程序。SCALE 将总缓存容量按比例划分为它们。例如，如果一半的应用程序不安全，则将一半的 LLC 容量分配给该组。SCALE 为非安全组单独调用 Lookahead，并对分配的容量进行分区。这为非安全应用程序提供了公平性，此外还确保非安全应用程序中的分配更改不会影响安全应用程序的分配。只有安全应用程序才会受到 SCALE 防御措施的影响。

7） 实用程序信息和软件支持
缓存分配策略需要硬件支持，以便估计具有不同缓存大小的未命中数。我们使用采样的UMONs来估计某种粒度的效用。实用程序计数器在每个重新配置周期后重置。SCALE 分配策略作为低级别软件运行时执行，在每个重新配置期间都需要操作系统干预。

B. 安全执行机制

1） DELTA
假设 DELTA 中的非安全执行机制，因为它适用于基于 tile 的 CMP，支持位置感知的数据放置，并使用 finc-grain 分区（例如，16 核 CMP 上有 256 个分区，每个 bank 有 16 个路）。我们首先概述了 DELTA 的执行机制。接下来，我们将解释如何调整 SCALE 以确保安全性、减少开销和简化设计。

DELTA概述：DELTA 提供两个主要功能，确保：（i） 通过分配算法分配给应用程序的容量放置在网络跃点数最少的bank中，以及 （ii） 将物理地址请求转发到映射数据的bank。

DELTA 使用每个内核缓存库表 （CBT），用于存储部分物理地址空间到 LLC 的映射，参见图 3。CBT允许跨多banl进行分配。该设计通过使用简单的 1 周期线性和反向哈希函数来确定地址映射到哪个组，该函数在设置索引之后获取地址的 8 位，将其反转，并将结果用作 CBT 的索引。请注意，哈希函数用于在占用的bank之间分配地址，并且 CBT 内容对每个应用程序都是私有的。使用此索引的 CBT 查找会生成地址映射到bank ID。一旦请求到达相应的bank行，就会执行标签查找。如果未命中，则 bank 中的 way 分区 （WP） 表（用于跟踪缓存方式和core_id之间的映射）会识别插入行的候选方式。在命中时，类似于英特尔的 CAT，允许跨分区边界访问数据，因为 DELTA 强制执行 LLC 中只有缓存行的单个副本的不变性。 CBT 和 WP 通过组合 bank 和 way 分区来实现细粒度的分区大小。在我们的模拟系统上，强制支持最小 32KB 的分区粒度，这是缓存库中单向的大小。有关CBT和WP的实施和存储成本的详细信息，请参阅DELTA。

当分配的缓存容量跨bank扩展/减少时，CBT 会更新。例如，考虑分配策略将 core0 上运行的应用程序的分配从 512KB 增加到 768KB。core0 上 CBT 的映射应从一个bank （bank0） 更新为跨两家银行（bank0 和 bankl），从而导致 CBT 更新。在本例中，核心 0 的原始 CBT 条目从0−255→0自0−191→0,192−255→1确保地址在两bank之间公平分配。映射到bank的地址范围与分配的大小成正比。

在 CBT 更新步骤之前，最初映射数据的缓存库中属于重新映射区域的所有地址都会失效。在这种情况下，重新映射的地址范围 （191-255） 中的缓存行从 bank0 中失效。更新了 bank0和 bank1中 WP 表中的内容以反映此更改。但是，bank1中新分配的方式中的内容不会失效。在 core0 上的 CBT 中映射到此索引的所有后续请求都将发送到 bank1而不是 bank0。此外，当私有页面被共享时，与页面关联的数据将从缓存中失效。这是因为 DELTA 仅使用 CBT 来确定私有页面中数据的映射。在地址转换过程中，将从 TLB 获取有关访问是私有页面还是共享页面的信息。要访问共享页面中的行，DELTA 将采用默认的 SNUCA 映射。

问题：尽管 DELTA 实施为细粒度和位置感知的数据放置提供支持，但设计中存在许多安全问题：（1） 允许在分区边界之外进行访问，（2） 缓存无法区分来自同一内核上不同进程的访问，（3） 替换策略通过元数据泄漏信息，（4） 保留共享数据的单个副本， （5）新分配bank的数据方式不作废。

调整：图 3 概述了 SCALE 的执行机制。SCALE利用域ID，就像其他安全缓存分区建议一样，用于识别用户进程和内核（id：0）。所有缓存请求都将使用域 ID字段进行标记。我们修改每个缓存库中的 WP 表，以存储缓存方式和域 ID 而不是核心 ID 之间的映射。在缓存查找和插入中，有关域 ID的信息用于限制对特定方式的访问，从而解决问题 1 和 2。

替换元数据：我们评估了两种变体，以避免替换策略元数据泄露。第一种通过对 LRU 状态进行分区 来隔离替换元数据，而第二种则仅使用随机替换策略。这两种变体都可以防止替换元数据泄漏并解决问题 3，同时在开销和性能方面提供不同的权衡。

缓存一致性：为了支持多线程应用程序，SCALE 将相同的域 ID分配给同一应用程序的不同线程。这将确保在应用程序线程之间共享的数据是缓存一致的。在其他情况下，当数据由不同的进程共享时，即使同一银行中已存在副本，也会重复数据，因为两个请求的域 ID字段不同。此外，缓存刷新指令 （CLFLUSH，CLWB） 将附加域 ID，并且仅影响具有匹配 ID 的分区。这些更改解决了问题 4。

最后，在原始设计中，CBT 重新映射仅在地址范围未映射的银行中触发失效（上例中的 bank0）。在 SCALE 中，我们以重新分配给另一个进程的方式使缓存行失效，以解决问题 5。在前面讨论的示例中，bank1中将分配给 core0的方法也无效。

上下文切换：保留上下文切换之间的 CBT 映射非常重要。因此，我们将 CBT 的内容以及特定区域中所有进程的域 ID存储在内核地址空间中。每个特定流程 CBT 的内容在上下文切换边界（如寄存器）保存和恢复。同样，在处理涉及从用户模式切换到内核模式的系统调用时，也会保存和恢复 CBT 的内容。请注意，这些开关不需要使缓存内容失效。

进程间通信：进程之间的数据传输需要以特殊方式处理，以确保安全性。不同分区中进程之间的数据传输需要通过系统调用和操作系统内核参与来处理，以确保隔离。内核和用户空间之间的数据传输需要硬件支持，以启用从用户复制和复制到用户等功能，从映射到用户域ID 的地址读取数据，并将数据写入内核域 ID 中的地址。

安全评估

效果评估

模拟了使用 Snipe建模的 16 核平铺 CMP 架构。每个切片都有一个无序 （OOO） 核心，该核心具有专用 L1 数据和指令缓存、统一的专用 L2 缓存和每个核心 512KB 的 L.L. 库。假设的缓存延迟已使用 CACTI 6.5 进行建模。

代码007普通

打赏 收藏 海报 链接