一种缓存感知的统一化Spectre攻击检测

A Unified Cache-Aware Detection for Spectre Attacks

摘要

推测执行攻击及其变种正在不断被推出，攻击在缓存中留下痕迹，再通过缓存侧信道将敏感信息泄露出去。然而，现有的针对Spectre攻击的检测对于Spectre攻击及各类变种的代码模式和防御手段分析不足，存在误报和漏报的情况。针对这一问题，提出了一种改进的缓存感知的动态分析方法，以识别多种Spectre攻击。基于攻击原理及代码模式特征对Spectre攻击多种变体进行分析建模，并提出了一种基于最近最少使用替换策略的抽象缓存模型；基于对Spectre攻击及缓存的建模实现了一个缓存感知的Spectre漏洞动态分析检测工具。通过分析建模、缓存状态感知和追踪实现了更全面和准确的检测。在一组微基准及常用的密码库上进行了实验，准确地检测出所有微基准样本中的Spectre漏洞，并在多个加密算法中检测到缓存侧信道及Spectre漏洞。实验结果表明，本文所实现的方法具有较好的检测能力。

Abstract

Spectre attack and its variants have been released continuously, leaving traces in the cache and then leaking sensitive information through the cache side-channel attacks. However, existing detection methods for Spectre attacks are insufficient for analyzing of the attack code patterns and existing defenses, resulting in false positives and negatives. This paper proposed an improved cache-aware dynamic analysis method to address this issue to identify various Spectre attacks. This paper analyzed and modeled variants of Spectre attacks based on the attack principle and code pattern characteristics, and improved the formal cache model based on the least recently used replacement policy, finally implemented a cache-aware dynamic analysis and detection tool for Spectre vulnerability based on the modeling of Spectre attacks and cache. Through experiments conducted on a set of microbenchmarks and commonly used cryptographic libraries, Spectre gadgets were accurately detected in all microbenchmark samples. Additionally, cache side-channel and Spectre vulnerabilities were identified in several cryptographic algorithms. In the end, the experimental results showed that the method proposed in this paper has a good detection capability.

Graphical abstract

关键词

Spectre攻击 / 缓存侧信道 / 侧信道检测

Key words

Spectre attacks / cache side-channel / side-channel detection

0　 引 言

侧信道攻击通过分析加/解密操作的非功能行为（如时间、功率、电磁辐射等）获取敏感信息。特别是在真实机器上实现应用时，开发人员通常会对其提出更多的要求，如性能优化，而不仅仅是考虑安全性。因此，侧信道攻击广泛存在于各种应用中，由于能够快速、隐蔽地泄露敏感数据，它已成为学术界和工业界都非常关注的安全问题。

基于缓存的侧信道攻击被证明是非常有效的。这些攻击起初被应用于AES^[1]、RSA^[2]等算法的密钥推测，后来被应用于更多现实的场景，包括云计算场景^[3]以及Intel SGX等具备可信硬件执行环境的场景中^[4，5]。

为了抵御缓存侧信道攻击，除了在硬件和系统底层进行侧信道修补外，一种有效的方法是检测软件程序中潜在的侧信道漏洞并进行修复。STACCO^[6]和CacheD^[7]通过收集程序执行路径，分析不同路径上的内存访问，检测侧信道漏洞点。MicroWalk^[8]、Diffuzz^[9]和ANABLEPS^[10]的检测思路相似，认为侧信道漏洞产生的主要原因是秘密相关的分支和内存访问模式。因此这些研究工作均检测在不同秘密输入下程序的执行时间和内存访问模式存在明显差异的地方，从而定位侧信道漏洞点。但它们没有对缓存进行分析，例如对于采用预加载对应表项进行侧信道防御的AES算法，将产生误报。CaSym^[11]采用了缓存感知的侧信道漏洞检测方法，对IR代码执行cache分析，构建cache状态公式作为验证条件并传递到SMT求解器。当该公式的可满足性达成则表示存在侧信道。

但上述方法仅关注了传统的缓存侧信道漏洞，没有考虑推测执行的情况。自2018年以来，基于CPU的推测执行优化机制的Spectre^[12]攻击及其变种^[13~16]被相继提出，相比于传统研究又创建了新的侧信道攻击面。攻击者通过将推测执行与缓存侧信道结合实现了跨内存隔离边界的读写。

针对此新攻击，oo7^[17]采用静态分析方法，通过控制流提取、污点分析检测受污染的条件分支和瞬态执行的内存访问，以识别二进制文件中潜在的Spectre代码片段。随后，Spectector^[18]使用符号执行来查找基于Spectre的信息泄漏，模拟多个步骤的错误预测分支的路径，分别在没有推测执行和错误预测情况下运行并记录不同路径的所有内存访问和跳转目标，若两个路径不匹配则认为存在Spectre代码片段。但该工作仅支持指令集中的小部分指令，并跳过其他指令，牺牲了分析的正确性。SpecFuzz^[19]则对模糊测试进行了扩展，通过在编译时将推测执行逻辑插入到原程序中来模拟推测执行。当在模糊测试过程中观察到越界内存访问就认为检测到了Spectre代码片段。SpecTaint^[20]则通过将攻击者可控的值设置为污点，对推测执行路径进行动态污点分析，将任何依赖于秘密的访问判定为Spectre代码片段。显然，上述检测方法缺乏对Spectre攻击及其变体的完整分析，仅针对Spectre V1进行了检测，忽视了其他变体攻击；对采用了针对Spectre攻击的软件防御方案的代码模式缺乏考虑，在代码采用了如数据掩码或LFENCE屏障的防御方案时可能出现漏报或误报的情况。

因此，针对以上问题，本文对Spectre多种攻击变体及缓存状态进行了详细的建模分析，并在建模的指导下设计了一种缓存感知的统一化Spectre攻击检测方案，基于动态二进制插桩、动态缓存状态检测及静态特征分析实现对漏洞的识别。主要做出以下贡献：

1） 分析了Spectre攻击多种变体的攻击原理，对多种Spectre攻击变体进行了建模，并探讨了当前已有防御中存在脆弱性的方案，以实现更全面地检测识别；

2） 提出了一种基于最近最少使用替换策略的抽象缓存模型，用于依赖于缓存状态的Spectre变体攻击和传统的缓存侧信道漏洞的识别，通过对缓存状态的感知和追踪实现更准确地检测；

3） 基于对Spectre攻击及缓存的建模实现了一个缓存感知的Spectre漏洞动态分析检测工具，并以Spectre样本库和OpenSSL加密库多种加密算法作为基准库展开了检测评估，通过与现有工作进行比较并对检测到的漏洞进行分析得出，该工具能够在合理时间内检测到多种Spectre变体及缓存侧信道，具有较好的检测能力。

1　 背景知识

1.1　缓存侧信道

侧信道攻击利用从计算机系统的物理实现中收集的信息窃取敏感数据。本文考虑了基于缓存的侧信道。我们将基于缓存的侧信道分为以下两类：依赖于秘密的内存访问和依赖于秘密的分支判断。

依赖于秘密的内存访问：即给定两个不同的秘密值，同一指令将加载不同的内存地址，例如AES加密算法中的查表操作，其访问的数组索引依赖于秘密值，从而导致可观察的缓存状态的差异，使攻击者可以利用侧信道攻击推测出秘密值。

依赖于秘密的分支判断：即给定两个不同的秘密值，可能导致同一条件跳转指令执行不同的分支，如果分支具有不同的内存访问模式，例如在RSA算法中应用的基于滑动窗口的平方差算法，执行的计算序列依赖于私钥位的取值，则会导致可观察的缓存状态的差异，因此攻击者可以使用侧信道攻击推测出秘密值。

1.2　Spectre攻击及其变体

现代CPU采用了许多优化机制来提高性能，其中包括推测执行。推测执行在分支、存储等指令不能立即获得结果时推测地执行后续指令（又称为瞬态指令）。如果预测失败，则撤销瞬态指令所做的更改，重新执行正确分支。但是，这些指令在微架构上留下的痕迹却不会被清除，给缓存侧信道攻击提供了新的攻击面。

利用这一机制，研究人员提出了多种Spectre攻击^[12~16]。我们将其简单分为以下几类：

1） 依赖于攻击者控制值的分支预测

在推测执行中，分支预测单元(Branch Predic-tion Unit, BPU)存储过去的分支方向和分支跳转目标并利用程序控制流中的局部性对未来的分支进行预测。BPU通过使用模式历史表(Pattern History Table, PHT)来预测是否采取该分支。假设攻击者可以控制输入值并预先通过重复训练以毒化PHT。在受害者执行过程中，分支语句可能难以立刻获得执行结果，此时被攻击者毒化的预测器将指向错误的分支预测方向，使攻击者控制的不合法输入值绕过边界检查并执行瞬态指令，实现跨内存隔离边界的数据的瞬态读取，随后基于侧信道攻击获取指令读取的敏感数据。

文献[12，21]通过实验验证了该攻击对多种处理器都造成了威胁，包括Intel Ivy Bridge、Haswell和Skylake处理器，AMD Ryzen处理器以及ARM架构的三星和高通处理器等。

随后，Kiriansky等^[13]展示了通过变体Spectre V1.1和V1.2实现绕过边界瞬态写。攻击原理与Spectre V1相同，攻击者在预训练后可通过控制不可信的值瞬态写入任意越界地址。而Spectre V1.2，则将覆盖写入的目标进一步地扩展到了只读数据、代码指针等以突破沙箱。

2） 依赖于敏感值相关的缓存状态的分支预测

对于条件分支，推测窗口大小取决于CPU验证实际分支目标与分支目标缓冲区提供的信息不同的时间，该时间容易受到变量的位置和附加计算的影响。例如，在缓存未命中或存在复杂的计算时，分支语句将花费较长时间才能获得执行结果，导致了较大的推测窗口大小。

如果存在分支指令，其推测窗口大小所依赖的缓存状态与秘密值取值有关，且不同大小的推测窗口将导致不同长度的指令序列的执行，进而导致不同的执行时间和缓存状态，那么攻击者就能够基于侧信道攻击间接地推测出秘密值。

3） 依赖于攻击者控制值的存储加载转发预测

Spectre V4^[14]依赖的是数据流中的依赖关系预测。按照存储加载依赖要求，在所有写入到同一位置的存储完成之前，内存加载不会执行。但为了提高性能，CPU采用了存储加载转发优化机制（Store-To-Load，STL），内存消歧器将在存储指令完成前预测一个加载不依赖于先前存储的地址，执行加载并读取数据，当已知所有先前存储的地址时验证预测，若发现重叠则说明预测错误，将重新执行加载和随后的所有指令。

Ragab等^[22]对内存消歧器进行逆向分析并得出结论：在最坏情况下，攻击者执行79对非重叠的存储-负载对就可以将内存消歧器训练为hoist状态，即预测加载指令不依赖于先前的存储。随后，攻击者就可以利用错误的预测读取旧值。

4） 依赖于缓冲区毒化的推测执行

在Spectre V2^[15]中，攻击者通过毒害分支目标缓冲区(BTB)来引导暂态执行转向一个错误预测的分支目标。与Spectre V1相反，该攻击允许将瞬态控制流重定向到任意目标。Spectre V5^[16]则通过重写或更新用于预测返回流的返回堆栈缓冲区(RSB)，将返回控制流转移到攻击者感兴趣的位置。这两类变体攻击采用已有的面向返回编程攻击技术，通过向缓冲区投毒将受害者地址空间中发现的选定代码链接在一起构建任意的瞬态指令序列。此类攻击理论上对于任意分支或返回指令都有效，不依赖于应用程序层的漏洞实现。

2　 Spectre漏洞特征建模分析

2.1　威胁模型

与之前的研究类似，我们假设攻击者与受害者位于同一台物理机器上。攻击者可以控制受害者的分支预测器，且能够与受害者共享缓存，并可以通过探测缓存的方式观察共享缓存的状态。此外，我们假设攻击者能够了解到受害程序每个程序点之后的缓存状态，以进行基于追踪的攻击。

其次，我们关注以下三类依赖于特定代码模式的Spectre变体攻击，即需要符合特定代码模式才能被攻击者利用。

1） 依赖于攻击者控制值的分支预测，包括Spectre V1，Spectre V1.1和Spectre V1.2；

2） 依赖于敏感值相关的缓存状态的分支预测，将其命名为Spectre-CS（Cache State）；

3） 依赖于攻击者控制值的存储加载转发预测，即Spectre V4。

对不同攻击变体依赖的硬件、攻击机制等的总结如表1所示。

对于Spectre V2和Spectre V5两类攻击，如表1所示，理论上所有间接跳转指令或返回指令都可利用，不依赖于应用程序层特定代码模式实现，不在本文考虑范围内，因此这里不进行讨论。

2.2　Spectre漏洞建模

本文的分析将关注上述三类Spectre攻击，并考虑程序使用了脆弱性防御的情况。通过形式化第1节中直观描述的Spectre攻击行为，对Spectre漏洞的特征进行具体的定义，为后续的检测实现提供指导。

为了对Spectre攻击进行形式化分析，对以下符号进行定义：

X：攻击者控制的输入值x的取值范围；

K：秘密数据key的取值范围；

C：条件分支指令；

R：内存读指令；

W：内存写指令；

M：内存操作指令，M=R\bigcup W；

O：攻击者能够观察的信息，包括缓存状态或执行时间等；

\left[l\right]：表示指令l的操作数；

\mathrm{s}\mathrm{w}：推测执行窗口，即瞬态执行的指令序列，若中途遇到fence等序列化指令则截断；

\mathrm{d}\mathrm{e}\mathrm{p}(l,d)：指令l的操作数依赖于数据d；

\mathrm{i}\mathrm{n}\mathrm{d}(x)：指索引取x值时不发生越界。

Spectre代码片段如图1所示，左侧为C代码，右侧是\mathrm{\mu }\mathrm{A}\mathrm{S}\mathrm{M}^[18]的汇编表示，黑体为漏洞可利用部分。

2.2.1　Spectre V1漏洞建模

Spectre V1代码片段如图1(a)所示，程序使用边界检查确保赋值给temp的索引变量x始终位于固定长度的数组A的边界内。然而，在攻击者重复提供有效的x值对PHT进行毒化训练后，PHT将始终预测此分支的计算结果为true。此时，即使攻击者提供了一个无效的越界索引x，CPU仍将沿着错误预测的路径暂态执行第5行的load操作，实现越界内存访问。在该代码片段中，根据正在读取的越界值，瞬态指令将属于数组B的另一个内存页加载到缓存中，此时攻击者通过缓存侧信道推测B被访问的缓存行，即可实现内存信息的泄漏。Spectre V1.1、Spectre 1.2代码片段如图1(b)所示，通过越界的可控值x瞬态将z值写入任意越界地址。

针对Spectre V1攻击及Spectre1.1、Spectre 1.2变体，为了更好地进行分析，我们将其形式化地表示为P_{\mathrm{1}}模型，如下式所示：

{{\rm P}}_{\mathrm{1}}=l_{\mathrm{0}}\in C\wedge \mathrm{d}\mathrm{e}\mathrm{p}\left(l_{\mathrm{0}},x\right)\wedge

\left(\exists l_{\mathrm{1}}\in \mathrm{s}\mathrm{w},\mathrm{d}\mathrm{e}\mathrm{p}\left(l_{\mathrm{1}},x\right)\wedge \right.

\exists x\in X\wedge \neg \mathrm{i}\mathrm{n}\mathrm{d}\left(x\right),\neg \mathrm{i}\mathrm{n}\mathrm{d}\left(\left[l_{\mathrm{1}}\right]\right)\wedge

\left.\left(\left(l_{\mathrm{1}}\in R\wedge \exists l_{\mathrm{2}}\in \mathrm{s}\mathrm{w}\wedge l_{\mathrm{2}}\in R,\mathrm{d}\mathrm{e}\mathrm{p}\left(l_{\mathrm{2}},[l_{\mathrm{1}}]\right)\right)\vee l_{\mathrm{1}}\in W\right)\right)(1)

即，当识别到与攻击者可控变量x相关的分支指令l_{\mathrm{0}}，若其瞬态执行窗口中存在依赖于x的内存操作指令l_{\mathrm{1}}，当x取不满足分支条件的越界值时，指令l_{\mathrm{1}}的操作数同样发生越界（即未采用数据掩码防御），且满足l_{\mathrm{1}}为内存写指令（Spectre V1.1和V1.2）或l_{\mathrm{1}}为内存读指令时，存在数据依赖于l_{\mathrm{1}}目的操作数的内存读指令l_{\mathrm{2}}（Spectre V1），我们就认为该处存在被第一类Spectre攻击利用的可能。

2.2.2　Spectre-CS漏洞建模

Spectre-CS代码片段如图1(c)所示，此时第4行的分支语句触发的推测窗口大小将取决于缓存状态，即A[0]是否被预加载。如果key为0，A[0]在第2行中被加载，那么第4行的分支语句将发生缓存命中，直接获得结果并执行正确的分支，否则将导致推测执行。若推测结果错误，将导致可观察的侧信道行为的差异。因此，攻击者可以推测出是否发生推测执行，进一步推测key值。

针对Spectre-CS攻击，我们将其形式化地表示为P_{\mathrm{C}\mathrm{S}}模型，如下式所示：

{{\rm P}}_{\mathrm{C}\mathrm{S}}=l\in C\wedge \exists k_{\mathrm{1}},k_{\mathrm{2}}\in K:O_{\mathrm{s}{\mathrm{w}}_{\mathrm{1}}}\ne O_{\mathrm{s}{\mathrm{w}}_{\mathrm{2}}}(2)

即，当检测到分支指令，且不同key的取值将导致攻击者观察到不同的推测执行行为，我们认为存在被Spectre-CS攻击利用的可能。

2.2.3　Spectre V4漏洞建模

Spectre V4代码片段如图1(d)所示，第3行的store操作触发推测执行，第4行load操作在推测错误的情况下将读取x执行与运算前的旧值。

针对Spectre V4攻击，为了更好地进行分析，我们将其形式化地表示为P_{\mathrm{4}}模型，如(3)式所示。

{{\rm P}}_{\mathrm{4}}=l_{\mathrm{0}}\in W\wedge \mathrm{d}\mathrm{e}\mathrm{p}\left(l_{\mathrm{0}},x\right)\wedge \exists l_{\mathrm{1}}\in \mathrm{s}\mathrm{w},l_{\mathrm{1}}\in R

\wedge \mathrm{d}\mathrm{e}\mathrm{p}\left(l_{\mathrm{1}},x\right)\wedge \mathrm{d}\mathrm{e}\mathrm{p}\left(l_{\mathrm{1}},\left[l_{\mathrm{0}}\right]\right)(3)

即，当检测到与攻击者可控变量x相关的内存写指令，如果其瞬态执行窗口中存在内存读指令l_{\mathrm{1}}，l_{\mathrm{1}}数据依赖于x且数据依赖于l_{\mathrm{0}}的目的操作数，我们就认为该处存在被Spectre V4攻击利用的可能。

2.3　Spectre漏洞防御方案分析

对于上述Spectre代码片段，开发人员采取了多种基于软件的防御修复方案^[23]，以下列出两种常见的防御方案：

1） FENCE防御：使用Fence等序列化指令阻止瞬态执行；

2） MASK防御：对索引进行掩码计算，阻止瞬态的内存越界。

在前一节对Spectre攻击进行建模时也考虑了这两种防御方案出现的情况。但需要注意的是，这两种方案均存在一定程度的脆弱性，没有真正消除Spectre攻击的隐患。在本节中，我们对这两种方案的脆弱性进行分析，并提出改进的安全防御方案。

2.3.1　采用FENCE防御的Spectre漏洞分析

软件可以在边界检查和后续操作之间插入一个屏障指令，如LFENCE指令或其他序列化指令。这类指令确保在所有前面的指令都在本地完成之前，不会执行后面的任何指令，即使是瞬态执行。

但Ren等^[24]提出通过在微操作缓存上创建争用来实现传输秘密信息的定时侧信道攻击，可以成功绕过fence指令。原理是：在LFENCE指令提交前，瞬态指令无法被分派执行，但间接分支和调用将触发微操作缓存访问以获取预测目标的微操作，在微操作缓存中留下足迹。因此，即使使用了fence指令，代码片段仍存在被利用的可能，代码片段如图2所示。

基于该防御方案的这一脆弱性，我们对推测窗口sw的定义进行完善，由原本的“遇到fence等序列化指令则截断”修改为“遇到fence等序列化指令，且其后续指令不是间接分支或调用指令时进行截断”。

因此，本文提出安全的FENCE防御如图3所示。在屏障指令lfence后增加一条nop指令，阻止微操作缓存对后续间接跳转或调用指令的目标地址的访问。

2.3.2　采用MASK防御的Spectre漏洞分析

对于基于数组索引越界的Spectre攻击，其中一种防御方案是对索引进行掩码计算^[25]，将其限制在边界内。

存在脆弱性的掩码防御方案如图4中所示，此时虽然防御了Spectre V1攻击，但同时又引入了新的Spectre V4攻击。当内存消歧器预测错误时，对数组A的访问将读取索引x掩码计算前的旧值，绕过MASK防御，执行Spectre V1攻击。

因此，可以通过Spectre V4漏洞检测实现对该脆弱性防御方案的识别。

通过创建寄存器变量来存储经过掩码计算的安全的索引值能够防御该攻击，如图5所示。此时，即使发生内存消歧器预测错误，将瞬态访问寄存器中的旧值0，不会发生内存越界。

3　 缓存状态检测

根据前面对Spectre攻击及缓存侧信道的分析可知，Spectre-CS及缓存侧信道攻击的实行依赖于缓存状态。Spectre-CS攻击中分支的推测窗口大小取决于分支判断中的数据是否已被载入缓存，而缓存侧信道攻击中基于分支的侧信道依赖于不同分支是否带来可观察的缓存状态差异。

因此，为了实现对这些漏洞的检测，我们需要引入缓存感知的路径追踪，结合缓存状态对漏洞进行检测。本节将对缓存进行建模，对缓存状态更新函数以及缓存一致性的判断进行定义。

本文基于CaSym^[11]中提出的采用最近未使用替换（Least Recently Used，LRU）策略的Age缓存模型进行改进，该模型对缓存状态的更新进行了抽象和简化。在文献[11]中基于该策略对缓存模型及缓存更新进行了如下建模：

1） 缓存状态\mathrm{c}\mathrm{e}即为从内存地址l到对应的年龄的映射，在初始缓存状态中将所有内存地址映射到的年龄设置为无穷；

2）当当前指令访问地址为l\text{'}时，将触发缓存更新函数，将访问地址l\text{'}的对应年龄置零，并将缓存状态\mathrm{c}\mathrm{e}中其他地址的年龄加1；

3）令N为缓存大小，根据\mathrm{c}\mathrm{e}\left(l\right)是否小于N判断地址l是否在缓存中，若满足，则认为两种缓存状态一致。

下面，我们将指出该模型存在的问题，并针对这些问题从缓存状态一致性定义以及缓存更新函数两个方面对模型进行改进。

3.1　对缓存状态一致性定义的改进

假设缓存大小N=\mathrm{4}，执行图6左侧的指令片段。

根据CaSym所述的模型定义，经过第1行对A、B、C、D四个元素的顺序访问，每次访问将当前访问元素年龄置零，并将其他元素年龄加1，此时的缓存状态\mathrm{c}\mathrm{e}变化过程如下：{ A:0, B:\mathrm{\infty }, C: \mathrm{\infty }, D: \mathrm{\infty } }→{ A:1, B:0, C: \mathrm{\infty }, D: \mathrm{\infty } }→{ A:2, B:1, C:0, D: \mathrm{\infty } }→{ A:3, B:2, C:1, D:0 }。同理，分别执行第3行和第5行两个分支，分别对元素A、C和元素B、D进行了访问，对应的缓存状态如图6右侧所示。此时，观察执行不同分支后获得的缓存状态，可见标灰部分的元素A、B不满足模型定义的缓存状态一致性判断：，将被检测为存在缓存侧信道漏洞。

但事实上，在进行了预加载的情况下，该代码应该是缓存侧信道安全的，因此基于CaSym模型的检测结果与实际情况不符，出现误报。

因此，对该模型进行改进。这里仅考虑LRU替换策略的情况，不对其他替换策略进行描述。

1）将缓存状态\mathrm{c}\mathrm{e}由内存地址到年龄的映射修改为存储内存地址及年龄元素的结构体的集合，并在集合中基于年龄进行排序。设置一变量c\_\mathrm{n}\mathrm{u}\mathrm{m}存储当前在缓存中的元素数量。在初始缓存状态中将所有内存地址的年龄设置为负无穷，将c\_\mathrm{n}\mathrm{u}\mathrm{m}设置为0；

2）令N为缓存大小，当当前指令访问地址l\text{'}时，将触发缓存更新函数。若地址l\text{'}的原年龄为负无穷，则将c\_\mathrm{n}\mathrm{u}\mathrm{m}加1。随后将访问地址l\text{'}的年龄置零，并将其他地址的年龄加1。若此时c\_\mathrm{n}\mathrm{u}\mathrm{m}>n，则将缓存状态\mathrm{c}\mathrm{e}中年龄最大的元素的年龄重新设置为负无穷，c\_\mathrm{n}\mathrm{u}\mathrm{m}减1；

3）根据内存地址l的年龄是否大于等于0来判断地址l是否在缓存中。为了方便理解，仍用\mathrm{c}\mathrm{e}\left(l\right)表示在缓存状态集合\mathrm{c}\mathrm{e}中地址l的年龄，若满足\forall l,\mathrm{c}{\mathrm{e}}_{\mathrm{1}}\left(l\right)\ge \mathrm{0}\leftrightarrow \mathrm{c}{\mathrm{e}}_{\mathrm{2}}\left(l\right)\ge \mathrm{0}，则认为两种缓存状态一致。

以图6中的代码为例，此时执行第1行、第3行和第5行的缓存状态与图6中所示相同，但基于改进后的一致性判断定义，此时三种缓存状态中的任意地址都同时大于等于0，符合缓存状态一致性，将被判断为缓存侧信道安全。

假设在if分支中访问新元素E，如图7所示。

此时将触发缓存更新函数，将E的年龄置零并将其他元素年龄加一，此时c\_\mathrm{n}\mathrm{u}\mathrm{m}>N，将集合中年龄最大的元素B的年龄设置为负无穷，如标灰部分所示，此时两个分支不再符合缓存状态一致性，我们将认为此处存在缓存侧信道。

3.2　对缓存更新函数的改进

在实际的内存访问中，缓存的载入和逐出都以缓存行为单位。假设元素A、B、C、D在内存中连续存储，加载时映射到同一缓存行中。将图6的第一行指令修改为load A，此时4个元素以缓存行为单位全部载入缓存中，该代码是缓存侧信道安全的，然而按照上一节的模型进行更新和缓存状态一致性判断，该代码将被视为存在缓存侧信道漏洞，导致误报。

因此，为了更贴近现实以实现更准确的缓存状态感知，缓存更新修改为以缓存行为单位。每次缓存更新时在缓存状态中查找与l\text{'}相邻的地址（除行内偏移外全部相同）并进行置零处理，如(4)式所示。其中，\mathrm{c}\mathrm{l}\left(l\text{'}\right)指l\text{'}所在的缓存行。

\mathrm{u}\mathrm{p}\mathrm{d}\mathrm{a}\mathrm{t}{\mathrm{e}}_c\left(l,\mathrm{c}\mathrm{e}\right)=\left\{\begin{array}{ll}\mathrm{0}& l\in \mathrm{c}\mathrm{l}\left(l\text{'}\right)\\ \mathrm{c}\mathrm{e}\left(l\right)+\mathrm{1}& l\notin \mathrm{c}\mathrm{l}\left(l\text{'}\right)\end{array}\right.(4)

设单个缓存行能存储的元素个数为L，若地址l的原年龄为负无穷，则在更新完成后将c\_\mathrm{n}\mathrm{u}\mathrm{m}加L。若此时c\_\mathrm{n}\mathrm{u}\mathrm{m}>N，同样以缓存行为单位进行逐出，将缓存状态\mathrm{c}\mathrm{e}中年龄最大的元素的年龄全部重新设置为负无穷，c\_\mathrm{n}\mathrm{u}\mathrm{m}减去L。

综上，原模型存在由于缓存一致性定义及缓存更新函数不准确导致侧信道检测与实际情况不符的问题，将导致误报。而本文的模型经过改进后，每次访问以缓存行为单位进行缓存状态更新，并修改缓存一致性定义为：若满足两个缓存状态中年龄大于0的元素一致，则认为缓存一致。解决了上述问题，使感知的缓存状态更加准确。

4　 Spectre漏洞检测实现

本节将根据第2节对缓存侧信道及Spectre攻击的分析建模及第3节设计的缓存模型，实现针对上述漏洞的缓存感知的动态检测工具。

4.1　漏洞检测流程

图8描述了针对多种Spectre攻击及缓存侧信道的漏洞检测的整个流程。

基于漏洞特征将其分为两类：依赖于输入x和依赖于密钥key。使用基于动态二进制插桩和两样本分布差异检验的DATA^[26]作为定位器，用于定位与x或key相关的分支和内存操作指令。

对于依赖于输入x的分支及内存读写指令，特征检测器基于第2节分析建模的Spectre V1（指Spectre V1及V1.1、V1.2这一类）和V4的代码模式特征对程序进行检测。

对于依赖于密钥key的分支及内存读写指令，缓存检测器基于第3节的抽象缓存模型实现，重复执行动态分析，通过缓存感知的执行路径追踪实现对缓存侧信道及Spectre-CS代码片段的识别。

4.2　针对Spectre V1和V4漏洞的特征检测

对于Spectre V1代码检测，定位基于x的分支指令，检测其推测执行窗口内是否存在两条基于x的内存读写指令，且后一条指令的源操作数与前一条指令的目的操作数存在传递关系。随后，进一步考虑是否进行了MASK防御的情况，模拟执行从分支指令到第一条内存读取指令间的指令序列，若对于不同输入，索引值始终位于边界内，则认为该代码序列满足Spectre V1安全，否则认为该代码序列存在受到Spectre V1攻击的可能。

对于Spectre V4代码检测，定位基于x的内存读写指令，该定位指令即图1（d）第4行的load操作，因此需要在推测执行窗口内向前回溯，检测算法如算法1所示。

首先，查找目的操作数与该指令源操作数部分匹配的内存访问指令，并向前递推，获取x相关值在寄存器中计算和移动的轨迹，使用深度优先遍历算法依次将这些寄存器存入队列中并逐个检测窗口内是否存在两条内存操作指令，其目的操作数与该寄存器部分匹配，则认为该代码序列存在受到Spectre V4攻击的可能。

4.3　针对Spectre‒CS和缓存侧信道漏洞的缓存检测

对于依赖于密钥key的分支及内存读写指令，基于建立的缓存模型进行再一次的追踪和检测。以触发依赖于密钥key的分支执行不同路径的密钥key作为程序的输入，对内存读写指令进行插桩，记录内存访问地址并更新缓存状态集合，形成trace，比较依赖于密钥key的跳转指令及不同分支的合并点（即两个分支重新交汇的指令）处的缓存状态，若两个trace在合并点处的缓存状态不一致，则认为存在缓存侧信道漏洞。

对于Spectre-CS代码检测，同样进行插桩和缓存感知的追踪。将依赖于密钥的内存访问处的缓存状态作为初始状态，向下查找分支指令，如果分支指令处的缓存命中状态，即缓存集合中是否发生了内存地址的年龄从负无穷到0的更新，与密钥取值存在相关性，则认为该代码序列存在受到Spectre-CS攻击的可能。

5　 实验结果评估

我们在Ubuntu 18.04的虚拟机上对本文实现的检测工具进行了测试，虚拟机配置为8 GB RAM和i5-8250U CPU 4核。推测窗口大小取值参照Speculator^[27]。我们选择了多种基准来评估该检测工具，包括:1） 15个易受Spectre V1攻击的知名样本^[28]，以及本文总结的除Spectre V1外的三种攻击和两种存在脆弱性的防御方案样本； 2） OpenSSL1.1.0f的一组常用加密算法。

5.1　微基准测试

首先，我们简要讨论对前两种基准样本的检测，使用编译器GCC默认编译选项O0进行编译。

该检测工具成功地识别了15个著名样本以及本文总结的变体及具有部分防御能力的Spectre攻击样本中的所有漏洞，插桩及分析过程平均耗时314.3 s。将本检测工具与其他现有的Spectre检测工作^[17~20]进行比较，结果如表2所示。

我们注意到表2中列举的现有工作均无法检测到Spectre-CS和Spectre V4攻击，而且均对FENCE防御方案可能存在的脆弱性缺乏考虑，导致漏报。对于掩码防御，由于oo7和SpecTaint工作在建模及检测过程中没有考虑掩码防御的情况，因此将忽略掩码的影响，无论是否存在掩码以及掩码存储方式是否安全，均将其检测为存在漏洞，因此在面对安全的掩码防御时将产生误报。而SpecFuzz和Spectector则由于没有考虑Spectre V4绕过掩码计算的情况，将采取掩码的防御方案全部判断为安全，导致出现漏报。

而本文的工具则更全面地覆盖了Spectre漏洞类型，能够准确地检测出上述样本是否存在相应漏洞，实现了更高的Spectre漏洞检测能力。

5.2　加密算法基准测试

接下来，我们在OpenSSL加密库上进一步评估本文的检测工具。将加密密钥视为秘密值，明文输入视为攻击者可控值，按照图8的工作流程进行依次地追踪和分析，检测结果如表3所示。

对于Spectre V1检测，在RSA加密中检测到两个符合定义的Spectre V1代码片段，如图9（a）和（b）所示（经简化）。两图中分支语句与3、4行内存读取语句均与x值相关，且内存读取语句的操作数存在传递关系。但检测到的代码片段中的分支指令均与明文输入值相关性较低，难以直接利用（如表3中第3列最后一行括号中的2表示检测到了两个符合Spectre V1特征的代码片段，但由于与明文输入值相关性较低，难以直接利用，所以从可利用性角度来说是检测到了0个）。

对于Spectre V4检测，以检测结果中的一个指令序列为例，如图10所示。最后一行是定位到的与x相关的内存访问指令。在第3行的mov操作作中可能会由于错误预测读取ebx寄存器中在执行异或操作前的旧值。

对于缓存侧信道漏洞，检测到的代码片段主要以内存访问为主，其中一个例子如图11所示，算法根据轮密钥的取值进行加载和计算，导致了依赖于key的内存访问。

由于加密算法库实现中较少存在与输入x、密钥key无关的分支判断，暂时没有检测到Spectre-CS的代码片段。

上述实验结果表明，我们的检测工具能够在合理时间范围内以较好的准确性检测到Spectre及缓存侧信道漏洞。

6　 结 语

针对当前Spectre检测工作均未对除Spectre V1攻击外的攻击变体进行检测且检测时不考虑对缓存状态的感知这一情况，本文提出了一种缓存感知的动态分析工具，实现了统一化的覆盖多种Spectre攻击变体的检测。在一组微基准测试及常用的密码库上的实验结果表明，本文提出的工具具有较好的检测能力，能较准确全面地检测出多种Spectre变体及缓存侧信道漏洞。

此外，由于Spectre V4攻击中利用的内存消歧器缺乏商用官方文档，在特定环境下别名预测机制与本文采取的操作数部分匹配方案可能存在差异，有偏差，对工作结果有一定影响。因此，未来工作方向是对内存消歧器的预测机制进行逆向分析，改进检测模型，也可针对未来新出现的攻击模式进一步扩展检测规则，提升检测能力。

参考文献

[1] OSVIK D A， SHAMIR A， TROMER E. Cache attacks and countermeasures： The Case of AES［M］//Topics in Cryptology — CT-RSA 2006. Berlin： Springer， 2006： 1-20. DOI： 10.1007/11605805_1 .

[2] PERCIVAL C. Cache missing for fun and profit［DB/OL］. ［2023-10-12］.

[3] WU Z Y， XU Z， WANG H N. Whispers in the hyper-space： High-speed covert channel attacks in the cloud［DB/OL］. ［2023-10-12］.DOI: 10.1109/tnet.2014.2304439 .

[4] BRASSER F， MÜLLER U， DMITRIENKO A， et al. Software grand exposure： SGX cache attacks are practical［DB/OL］. ［2023-10-12］.

[5] 杨帆， 张倩颖， 施智平， 等. 可信执行环境软件侧信道攻击研究综述［J］. 软件学报， 2023， 34（1）： 381-403. DOI： 10.13328/j.cnki.jos.006501 .

[6] YANG F， ZHANG Q Y， SHI Z P， et al. Survey on software side-channel attacks in trusted execution environment［J］. Journal of Software， 2023， 34（1）： 381-403. DOI： 10.13328/j.cnki.jos.006501 （Ch ）.

[7] XIAO Y， LI M Y， CHEN S C， et al. STACCO： Differentially analyzing side-channel traces for detecting SSL/TLS vulnerabilities in secure enclaves［EB/OL］.［2023-10-11］.DOI: 10.1145/3133956.3134016 .

[8] WANG S， WANG P， LIU X， et al. CacheD： Identifying cache-based timing channels in production software［EB/OL］.［2023-10-11］.

[9] WICHELMANN J， MOGHIMI A， EISENBARTH T， et al. MicroWalk： A framework for finding side channels in binaries［EB/OL］.［2023-10-11］. DOI: 10.1145/3274694.3274741 .

[10] NILIZADEH S， NOLLER Y， PASAREANU C S. DifFuzz： differential fuzzing for side-channel analysis［C］//2019 IEEE/ACM 41st International Conference on Software Engineering （ICSE）. New York： IEEE Press， 2019： 176-187. DOI： 10.1109/ICSE.2019.00034 .

[11] WANG W B， ZHANG Y Q， LIN Z Q. Time and order： Towards automatically identifying side-channel vulnerabilities in enclave binaries［EB/OL］.［2023-10-11］.

[12] BROTZMAN R， LIU S， ZHANG D F， et al. CaSym： cache aware symbolic execution for side channel detection and mitigation［C］//2019 IEEE Symposium on Security and Privacy （SP）. New York： IEEE Press， 2019： 505-521. DOI： 10.1109/SP.2019.00022 .

[13] KOCHER P， HORN J， FOGH A， et al. Spectre attacks： Exploiting speculative execution［C］//2019 IEEE Symposium on Security and Privacy （SP）. New York： IEEE Press， 2019： 1-19. DOI： 10.1109/SP.2019.00002 .

[14] KIRIANSKY V， WALDSPURGER C. Speculative buffer overflows： Attacks and defenses［EB/OL］. 2018： arXiv： 1807.03757.

[15] HORN J. Speculative execution， variant 4 ： Speculative store bypass， 2018［EB/OL］.［2023-10-11］.

[16] BHATTACHARYYA A， SANDULESCU A， NEUGSCHWANDTNER M， et al. SMoTherSpectre： Exploiting speculative execution through port contention［EB/OL］.［2023-10-11］.DOI: 10.1145/3319535.3363194 .

[17] KORUYEH E M， KHASAWNEH K N， SONG C Y， et al. Spectre returns！ speculation attacks using the return stack buffer［C］//IEEE Design & Test. New York： IEEE Press， 2024： 47-55. DOI： 10.1109/MDAT.2024.3352537 .

[18] WANG G H， CHATTOPADHYAY S， GOTOVCHITS I， et al. oo7： Low-overhead defense against spectre attacks via program analysis［J］. IEEE Transactions on Software Engineering， 2021， 47（11）： 2504-2519. DOI： 10.1109/TSE.2019.2953709 .

[19] GUARNIERI M， KÖPF B， MORALES J F， et al. Spectector： Principled detection of speculative information flows［C］//2020 IEEE Symposium on Security and Privacy （SP）. New York： IEEE Press， 2020： 1-19. DOI： 10.1109/SP40000.2020.00011 .

[20] OLEKSENKO O， TRACH B， SILBERSTEIN M， et al. SpecFuzz： Bringing spectre-type vulnerabilities to the surface［EB/OL］.［2023-10-11］.

[21] QI Z X， FENG Q， CHENG Y Q， et al. SpecTaint： Speculative taint analysis for discovering spectre gadgets［EB/OL］. ［2023-10-11］. DOI: 10.14722/ndss.2021.24466 .

[22] 刘畅， 杨毅， 李昊儒， 等. 处理器分支预测攻击研究综述［J］. 计算机学报， 2022， 45（12）： 2475-2509. DOI： 10.11897/SP.J.1016.2022.02475 .

[23] LIU C， YANG Y， LI H R， et al. A survey of branch prediction attacks on modern processors［J］. Chinese Journal of Computers， 2022， 45（12）： 2475-2509. DOI： 10.11897/SP.J.1016.2022.02475（Ch ）.

[24] RAGAB H， BARBERIS E， BOS H， et al. Rage against the machine clear： A systematic analysis of machine clears and their implications for transient execution attacks［EB/OL］.［2023-10-11］.

[25] 吴晓慧， 贺也平， 马恒太， 等. 微架构瞬态执行攻击与防御方法［J］. 软件学报， 2020， 31（2）： 544-563. DOI： 10.13328/j.cnki.jos.005979 .

[26] WU X H， HE Y P， MA H T， et al. Microarchitectural transient execution attacks and defense methods［J］. Journal of Software， 2020， 31（2）： 544-563. DOI： 10.13328/j.cnki.jos.005979 （Ch ）.

[27] REN X D， MOODY L， TARAM M， et al. I see dead µops： Leaking secrets via Intel/AMD micro-op caches［C］//2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture （ISCA）. New York： IEEE Press， 2021： 361-374. DOI： 10.1109/ISCA52012.2021.00036 .

[28] OLEKSENKO O， TRACH B， REIHER T， et al. You shall not bypass： Employing data dependencies to prevent bounds check bypass［EB/OL］. 2018： arXiv： 1805.08506.

[29] WEISER S， ZANKL A， SPREITZER R， et al. DATA—differential address trace analysis： Finding address-based side-channels in binaries［EB/OL］.［2023-10-11］.

[30] MAMBRETTI A， NEUGSCHWANDTNER M， SORNIOTTI A， et al. Speculator： A tool to analyze speculative execution attacks and mitigations［EB/OL］.［2023-10-11］. DOI: 10.1145/3359789.3359837 .

[31] KOCHER P. Spectre mitigations in microsoft’s C/C++ compiler［EB/OL］.［2023-10-11］.

基金资助

国家重点研发计划项目(2022YFB3103804)

国家自然科学基金(62102290)

湖北省重大研究计划项目(2023BAA027)

湖北省重点研发计划(2020BAA003)

湖北省重点研发计划(2021BAA027)