缓存侧信道防御研究综述

随着Spectre[1],Meltdown[2],Foreshadow[3],ZombieLoad[4]等一系列CPU硬件漏洞的发现，人们在研究应用软件和操作系统漏洞的同时，也开始重视硬件层面，尤其是由于硬件架构特点而引发的安全威胁.侧信道攻击是利用计算机硬件的一种主要的攻击方式，它利用微架构状态开展攻击，可能会造成用户的信息泄露；同时，它也具有较高的隐蔽性，对用户信息和设备安全带来极大的安全威胁.

侧信道攻击[5](side channel attack, SCA)，是指对软件在物理设备上执行过程中暴露出来的某些特征，如声音、电磁辐射、温度等侧信道信息(side channel information)分析，得出设备内部的执行情况，推断出用户信息的一种攻击方式.这种攻击方式常用来绕过加密算法等安全机制提供的安全性，造成用户信息泄露.一般而言，侧信道攻击具有3个方面特点[6]：1)难以检测，大部分侧信道攻击不需要特殊的权限，只要能够完成对侧信道信息的采集，就可以开展后续分析；2)防御成本高，减缓侧信道攻击会对系统的性能带来很大影响；3)平台依赖性高，侧信道攻击利用的不是算法或程序本身存在的问题，而是程序的实现及运行过程中存在的问题进行攻击，严重依赖于程序的执行环境以及硬件架构等.而基于微架构的侧信道攻击是近年来新兴的一种侧信道攻击方式，它对处理器缓存(cache)[1-4,6-24]、内存管理单元(memory management unit, MMU)[25]、快表(translation lookaside buffer, TLB)[26]、总线(bus)[27]等微架构进行监控，并根据一些先验知识获取出用户程序的执行状态，从而造成用户信息泄露.

微架构侧信道攻击利用CPU硬件上的漏洞展开攻击，它属于一种来自硬件的威胁.处理器缓存具有3个特征：1)目前绝大多数处理器中有缓存结构;2)缓存可以拥有一个系统细粒度的数据访问和指令执行的状态信息;3)缓存状态不同时，程序的执行结果相同，但运行时间等外部特性会存在较大的差异.攻击者可以通过这些特征可以很方便地构建侧信道，因此这种攻击方式最具有吸引力，相关研究也相对较多.2006年Osvik等人[8]使用Prime+Probe实现了在同一个处理器核上的侧信道攻击，并展示了如何获取出AES加密算法的密钥，随后，由此展开了对这种攻击方式的研究.2009年Ristenpart等人[9]将这种攻击方式扩展到云环境中，在EC2服务器上完成了微架构侧信道攻击.但是之前的攻击方式都是使用第一级缓存进行攻击，攻击的范围和能力都相对有限，Yarom等人[10]首次使用共享库利用最后一级缓存(last level cache, LLC)完成跨核侧信道攻击.随后，Liu等人[14]对不存在共享库等共享文件的前提下使用LLC完成侧信道攻击的难点进行分析，并成功使用Prime+Probe实现了跨核微架构侧信道攻击.

微架构侧信道攻击尤其是基于缓存的微架构侧信道攻击严重威胁用户的信息安全，造成用户密码等敏感信息泄露.缓存侧信道攻击防御措施的相关研究工作主要围绕重构软件代码、增加操作系统功能等方面展开.文献[28-29]从缓存侧信道攻击手段、防御方式等角度对缓存侧信道攻击的相关工作进行归纳总结；文献[30]重点考虑了嵌入式设备和云环境中的相关防御手段.但是这些研究只是从防御的具体措施、实施方法的角度和防御的层次对现有防御手段进行分类，没有从攻击模型的角度解释防御的安全性，同时对硬件架构的关注相对较少.因此，本文从攻击模型角度对现有的防御措施进行分析比较，重点介绍了新型安全缓存架构设计方案.

本文的主要贡献有3个方面：

1) 总结归纳缓存侧信道攻击的模型，并结合攻击模型讨论具体的攻击步骤；

2) 对现有的防御手段进行分析比较；

3) 讨论缓存侧信道攻击防御措施面临的挑战以及未来研究方向.

1 缓存侧信道攻击

基于缓存的侧信道攻击可以实现跨进程、跨处理器核以及跨虚拟机的攻击，这种攻击方式对市面上几乎所有主流架构的处理器(如Intel,AMD,ARM[31])等都有效，攻击的范围涵盖RSA,AES,ECC等加密算法及其他软件甚至操作系统，可以在本地处理器上甚至远程虚拟机上开展攻击.

本节首先结合RSA加密算法，介绍了缓存侧信道“漏洞”“攻击粒度”以及具体的攻击过程；之后讨论了缓存侧信道攻击模型.

微架构侧信道“漏洞”是指可执行程序的某一部分区域，它可以位于代码段，也可以位于数据段，这段代码或数据本身逻辑和设计没有什么问题，但是这部分内存区域与用户敏感信息相关，攻击者可以利用这段代码的执行情况或数据的访问情况判断出用户信息，从而造成用户信息泄露.例如，对于平方-乘算法而言，由于算法1行⑦～⑩是一个与用户密钥相关的代码分支，也就是说，攻击者可以根据这一分支的执行情况推断出用户密钥，因此称算法1行⑦～⑩为微架构侧信道“漏洞”.

算法1. 平方-乘算法.

① function exponent(b,e,m)

④ for i=|e|-1 downto 0 do

攻击者可以通过用户程序的整体执行时间“监听”，也可以通过内存访问情况“监听”获取用户程序执行信息，不同攻击方式的信息来源不同，“监听”手段不同，我们称攻击者“监听”用户程序的手段为攻击者的攻击粒度.

一般来讲，根据微架构的侧信道攻击的获取信息的来源，可以把攻击方式分为：时间驱动(time-based)攻击、访问驱动(access-based)攻击[32]和踪迹驱动(trace-based)攻击，表1从信息来源、具体特点以及代表攻击手段对3种攻击方式进行了比较.“Evict+Time”[8]是时间驱动攻击的典型代表，具体的攻击过程为：

1) 攻击者测量程序在正常工作下执行所需要的时间；

2) 攻击者根据之前确定的漏洞，填充对应位置缓存，把这部分内容从缓存中“清除”；

3) 攻击者再次测量程序执行所需要的时间，利用整体上的时间差异判断用户程序的执行流程.

攻击者可以通过程序整体执行的时间差异推测出程序的执行流程，此时攻击粒度为整个用户程序.但是，这种攻击方式需要多次触发用户程序，且需要判断程序的整体执行时间，精度较差，探测时间较长，因此这类攻击方式应用范围相对较小.

“Flush+Reload”[10,33]是访问驱动攻击的典型代表，这种攻击方式的攻击粒度为一个缓存块，具体攻击步骤为：

1) 攻击者根据具体的处理器判断缓存命中与缺失的阈值；

2) 根据之前确定的漏洞，flush指令强制清除对应位置的缓存块；

3) 等待用户程序执行；

4) 重新载入漏洞位置代码，根据这次访问时间与阈值的关系，判断用户程序执行情况.

而踪迹驱动需要采集加密算法执行过程中所有缓存访问的命中和缺失序列[12]，并结合明文或密文推测出用户密钥，踪迹驱动的攻击方式能够获取的信息最多，但往往需要操作系统等的支持才能获取所有缓存访问情况.

在3种攻击中，踪迹驱动需要系统提供的信息最多，需要能够对系统进行持续的探测，精度也最高；时间驱动只需要对程序的执行时间进行探测，利用不同硬件状态的不同执行时间，但是容易受到外界噪声的干扰；访问驱动需要能访问与用户所使用的资源，判断用户是否执行过与该区域相关的访问操作.

1.1 攻击者能力

在讨论基于缓存的侧信道攻击模型之前，我们首先假定攻击者具有3方面能力：

1) 攻击者要与被攻击的对象存在共享的硬件资源，包括缓存、总线等；

2) 攻击者可以随意访问自己用户空间中的内存；

3) 攻击者可以测量访问某个内存所需要的时间.

这些条件在现代计算机系统中或者云环境中基本能够满足.

一般而言，缓存侧信道攻击可以根据攻击的目标分为针对主机的攻击和针对虚拟机的攻击；根据攻击的模式可以分为隐蔽信道攻击和侧信道攻击；根据攻击对象把攻击分为针对不同加密算法的攻击、针对操作系统的攻击等.本文按照攻击者对缓存的利用方式不同，把攻击分为基于复用的缓存侧信道攻击和基于冲突的缓存侧信道攻击.

基于复用的缓存侧信道攻击，指攻击者与用户存在共享内存，例如共享的库、共享文件等，且攻击者利用的“漏洞”存在于共享内存中，攻击者可以获取到该区域的内存访问模式.

基于冲突的缓存侧信道攻击是指，攻击者与用户不存在共享内存，或有可能存在共享内存，但是“漏洞”不存在于共享内存中，攻击者只能通过对自己的地址空间中的内容访问，影响正常用户进程中对缓存的使用，推断出用户对某物理地址的访问模式.

1.2 攻击步骤

如图1所示，根据攻击者实施基于缓存的微架构侧信道攻击需要采取的操作，攻击过程可以分为4个步骤：

1) 确定“微架构侧信道漏洞”；

2) 确定攻击者与用户程序的“冲突域”；

3) 攻击者通过“冲突域”对“微架构侧信道漏洞”的位置进行监听，获取出微架构状态的变化；

4) 攻击者根据获取到的信息以及一些先验知识，还原用户信息.

本节根据之前讨论的攻击者能力按照攻击模型对攻击步骤进行详细介绍.

1.2.1 确定“漏洞”

根据“漏洞”的目标程序对应地址所包含的内容不同，微架构侧信道漏洞主要包括两大类：1)基于指令执行的漏洞；2)基于数据访问的漏洞.

基于指令执行的漏洞是指用户程序在执行过程中，存在与用户信息相关的指令控制流，例如把用户信息作为分支跳转指令的转移条件等.通过这些对这些指令的监控，攻击者可以分析出用户的指令执行过程，之后对攻击者的信息进行推断；基于数据访问的漏洞是指用户程序访问的数据与用户信息相关，例如把用户信息作为索引，查找某个地址的数据内容.攻击者可以通过观察这些内存的访问情况，获取出用户信息.

攻击者在攻击过程中，首先要确定出“漏洞”源，才能对“漏洞”确定的地址进行“监听”.

1.2.2 确定“冲突域”

根据攻击者和用户共享的层面不同，攻击可以分为跨进程攻击、跨处理器核攻击、跨虚拟机攻击.与其他的攻击方式相比，跨虚拟机的攻击首先要进行“虚拟机同驻”的判断，即判断攻击者和用户所在的虚拟机之间的关系是处于同一个处理器核，还是同一个处理器中不同的处理器核上；或者不同的虚拟机运行于不同的处理器上.通过“虚拟机同驻”判断，可以分析出攻击者与用户之间的共享结构，就可以把问题转化为其他2种攻击方式.

如图2的处理器共享层次所示，跨进程攻击是指攻击者和用户运行于同一个处理器核之上，可以共享的资源包括缓存、内存、内存控制器等资源；跨处理器核攻击是指当攻击者和用户运行于不同的处理器核之上，可以共享的资源包括最后一级缓存、内存等；跨虚拟机攻击主要指在多租户的云服务器中，攻击者和用户位于不同的虚拟机之上[34]，完成“虚拟机同驻”后，跨虚拟机的攻击方式与其他2种攻击的攻击方式无异，而当处理器位于不同的物理封装时，共享内存控制器同样会成为被攻击的对象[35].

当攻击者利用的“漏洞”存在于共享内存中时，攻击者可以通过对该“漏洞”对应地址进行直接访问，影响“漏洞”对应内容在缓存中的状态；而“漏洞”不存在于共享内存中时，攻击者则需要首先分析出一组“虚拟地址集合”，攻击者通过这个集合影响“漏洞”对应的代码或数据在缓存中的状态，这个集合被称为“冲突域”.

具体来讲，冲突域[36]是一组虚拟地址的集合，攻击者可以访问这个集合中的地址.它具有3个特点：

1) “冲突域”与目标地址影响同一个缓存微架构状态(比如都可以对同一块Cache的状态产生影响).

2) 通过冲突域的访问可以把目标地址所涉及到的微架构状态初始化到攻击者可以控制的状态.

3) 通过冲突域的访问可以感知目标地址对应的微架构状态的变化.

当选取的“冲突域”太大时，一方面造成比较大的“噪声”，对攻击过程产生影响；另一方面会增加攻击的时间.因此在寻找“冲突域”的过程中，较小的冲突集(small conflict groups, SCG)对攻击过程更有意义[13].一般来讲，攻击者选择的冲突域的大小与缓存关联度相同[36-37].

微架构状态的不同，不会对程序的执行结果产生影响，但是会对程序执行过程产生影响.具体可以有3个方面的效果：

1) 执行时间的区别.数据或代码位于不同的存储器层次结构时，访问时间会存在较大的差异.对于Xeon E5-2430处理器[10]从LLC读取数据需要55～82个时钟周期，而从内存中读取数据则需要230个时钟周期；而对于Intel i5-2430M处理器[16]，访问LLC需要50个硬件周期，而访问内存则需要220个时钟周期.

2) 引发中断事件.在使用Intel TSX指令的时候，当检测到缓存被驱逐时，会引发事务中断[21],攻击者可以捕捉这些事件，对用户行为进行分析.

3) 硬件结构资源使用情况.程序在执行过程中，有可能对某些硬件单元独占或锁定[27]，导致别的程序不能使用，攻击者可以通过对这些硬件资源的检测，分析用户正在执行的一些操作.

但是，对中断事件的捕获，需要操作系统的支持，对某些硬件结构进行监控分析，精度较差，应用范围相对较小.而缓存几乎存在于所有的处理器中，且粒度较细，精度较高，因此把缓存状态作为获取信息的途径是最为广泛的.

攻击者通过缓存状态获取的信息，需要有一个比较精确的时间统计信息，判断“漏洞”位置所处的存储器层次结构.目前攻击者获取“精准时钟”有3个途径[38]：

1) 硬件内部的时钟源；

2) 其他计算机或设备的时钟源；

3) 软件生成的虚拟时钟源.

攻击者获取到微架构状态信息的变化后，需要根据一定的先验知识，对获取到的内存访问模式等信息进行处理，包括消除信息中的噪声、还原信息的控制流、还原用户内存访问情况等.通过这些操作及分析，攻击者可以获取密钥[16]、用户行为信息[13]、内核空间的分布信息[24]等.

但是，在实际的攻击过程中，这一步往往是通过离线操作进行的，攻击者不需要再与用户进行信息交互，也不需要“监听”内存访问情况，因此攻击者就不需要过多关注“执行环境”，而本文重点关注攻击者在攻击过程中对硬件结构等的利用情况，讨论攻击者和用户通过“硬件架构”完成“交互”，因此这部分不作为本文的讨论内容.

2 防御措施

根据1.2节攻击步骤的讨论，攻击者想要实施侧信道攻击，首先就要判断出“监听位置”，即找到缓存侧信道“漏洞”；其次需要确定“监听手段”，即“冲突域”；最后攻击者才能“监听”出用户程序的执行情况，完成信息窃取.

若攻击者完成信息窃取之前的相关工作，攻击也就无从谈起.因此，根据防御的目的和效果，本文把目前的防御手段分为代码检测、缓解“漏洞”、降低测量精度3类.

2.1 代码检测

缓存侧信道检测技术(cache side channel detec-tion technology)，即代码检测技术，是指通过检测用户程序，判断所执行程序中是否存在可以被缓存侧信道所利用的“漏洞”的技术.它从用户程序的角度实现对缓存侧信道的防御.

表2列举了近年来关于代码检测工具的相关研究，并从检测工具的分析方法、输入输出、可以发现的漏洞类型，以及是否需要用户程序的源代码角度进行比较，最后展示了各个检测工具的分析性能.

代码检测技术主要包括两大类：静态分析和动态分析.Doychev等人[39]及其扩展工作[40]使用抽象解释的方式，对3种常见的基于Cache的攻击方式进行分析，首次采用自动化的方式检测缓存侧信道漏洞.CacheAudit及其扩展工作给出的是用户由于微架构侧信道漏洞存在造成的信息泄露的上限，但是有可能会给出一个过高的上限而导致结果无意义.也就是说，CacheAudit工具只能验证代码的安全性，而不能判断代码是不安全的.

静态分析的方式虽然具有较高的代码覆盖率，但是只能对程序是否存在侧信道的风险进行判断，不能准确地描述出漏洞的具体位置和漏洞的成因.Zankl等人[41]使用PIN作为动态二进制测量工具，对二进制代码运行过程中的执行过程的内存访问情况进行跟踪，检测微架构侧信道漏洞的位置.此外，Carré等人[42]采用动静结合的分析方式，把依赖于密码的控制流或者依赖查找表作为可能的侧信道漏洞点，在“可疑点”处设置断点，统计代码的执行数目和访问模式，对代码中存在的这些可能的漏洞进行进一步的确认，但是在分析过程中，单纯考虑了内存查找表访问和控制流程，没有过多地考虑Cache本身的影响.针对这个问题，Irazoqui等人[43]在MI-Tool中首先使用KLEE作为污点分析的工具，分析出密码相关的指令或数据，之后在这些“疑点”前后分别插入Cache强制清除和Cache重新访问的代码，使用不同的输入执行代码，获得Cache的踪迹，最终对这些“疑点”是否属于侧信道进行验证.

之前的检测工具虽然可以对用户程序进行检测，但是代码覆盖率相对较低，且没有展示出攻击者对“漏洞”的具体利用手段.随后，Brotzman等人[44]提出CaSym，为了避免不同的编译器对检测工具的影响，CaSym使用IR-level代码作为输入，并对Cache的行为建模，使用抽象的Cache模型，使用符号执行对程序的执行路径进行分析，对目前已知的基于Cache的攻击方式进行检测.CacheD[45]将一个具体的程序执行踪迹作为输入，并在符号执行期间符号化敏感信息，以识别敏感信息相关的内存访问.CacheD探索与输入动态跟踪相同的执行路径.但是只能探测与输入相同的路径，那些未被探测的代码中的漏洞或那些由依赖于秘密的分支引起的漏洞不能被缓存检测到.Weiser等人[46]开发了DATA工具.该工具使用不同输入激励多次执行程序，找出程序执行过程中地址轨迹的不同点；再用一个固定的输入与多个随机的输入，统计找出真正的泄漏点，最后对安全关键软件进行测试和验证，揭示用户秘密信息与程序执行之间的依赖关系.

漏洞,“×”表示不能检测出这种类型漏洞.

代码检测不能同时兼顾高精度、代码覆盖率以及整个系统的扩展性，因此在实际使用过程中受到了很大的限制.Wang等人[47]发现程序的密钥信息以及其依赖关系通常只会在很小的一个程序上表现，其他大量的变量只是用来维护公共信息.根据这个特点，他们设计了“秘密增强符号域”(SAS)，开发了一个新的静态检测侧信道漏洞的工具——CacheS，对密钥相关的代码进行细粒度的分析，而对其他代码采用可伸缩的探测方式.通过这种分析方式，作者定位出了54个之前没有提及的漏洞点.此外，Gridin等人[48]利用GDB调试工具开发了Triggerflow，在源注释的帮助下动态分析二进制文件，可以以一个较快的速度发现OpenSSL库中可能存在的缓存侧信道风险.

为了能够对编译器的输出进行分析，Wichelmann等人[49]开发了一种可扩展的MicroWalk框架，并对2个广泛应用但闭源的加密算法库Intel IPP和Microsoft CNG中的15个不同的加密算法进行验证，解释了二进制代码中是否存在缓存侧信道风险、缓存侧信道风险的位置以及缓存侧信道漏洞点的位置与密钥的关系等相关问题.

之前的代码检测工具可以对用户程序中的基于数据访问或控制流的“漏洞”进行检测，但是对Spectre[1]等攻击方式却无能为力.SpecFuzz[50]首次使用动态分析的方式实现了对代码中潜在的预测执行漏洞进行判断，SpecuSym[51]基于符号执行的方法，系统地探测用户执行空间，对分支的推测行为进行建模.在动态执行期间，检查缓存行为，判断可能出现的风险.

2.2 缓解“漏洞”

代码检测只能判断用户程序中是否存在“漏洞”，但是却不能消除“漏洞”.因此，本节对常用的缓解缓存侧信道攻击的技术进行归纳总结.

目前常见的缓解“缓存侧信道漏洞”的方法主要包括：恒定时间技术、缓存清除以及编译器辅助安全措施等.恒定时间技术(constant-time technology)[52]是一种用于抵抗基于微架构的时间侧信道攻击的有效手段.其主要思想是通过软件的方式，使不同表项和指令流的执行过程中的访问时间相同，避免程序执行时间与执行流程之间的相关性，从而消除“侧信道漏洞”.NaCl[53]避免从密码到加载地址和分支预测的数据通路，消除了许多已经发现的漏洞；Andrysco等人[54]设计了一个固定时间的数学库libfixedtimefixpoint，使用“恒定时间”策略，保证程序本身的安全性.Panda[55]采用了一种“向后缺失触发硬件预取技术”(BITP)，在攻击者“观察”内存访问模式之前把缺失内容完成硬件预期，不需要软件、操作系统的支持，就可以消除攻击者的观察接口，使攻击者无法观察到用户的内存访问模式.表3所示为缓解缓存侧信道的技术.

对于恒定时间技术而言，一方面需要解决如何实现“恒定时间”，另一方面是如何“验证程序是恒定时间的”.而且，随着程序规模的扩大，如何确定程序是“时间固定的”，是一个具有挑战性的问题.Almeida等人[56]对程序进行LLVM级逻辑验证，开发了用于分析程序“恒定时间特征”的自动化验证工具ct-verif，在NaCl,OpenSSL,FourQ等多个商用的库上进行验证，较为快捷地实现了“恒定时间”的验证.但是程序执行与硬件架构相关，因此需要从汇编代码级别对程序进行分析.Bond等人[57]开发了Vale工具，把带注释的汇编语言转化为抽象语法树，在ARM和X86平台上对SHA-256算法、X64平台的Poly1305的代码进行分析，结果表明：Vale可以对现有代码的正确性、安全性进行验证.对于二进制代码而言，Daniel等人[58]开发了BINSEC width=5,height=17,dpi=110

REL，对程序的执行流进行分析，并通过对338种密码的实现方案进行验证，极大地提高了对代码恒定时间的验证速度和精度.此外，文献[59]中使用静态信息流分析的方法对加密算法库中的代码进行验证.

缓存清除技术(cache flushing technology)，是指通过操作系统等的辅助，清除由于用户程序执行带来的微架构状态的变化.Zhang等人[60]周期性地清除L1缓存，消除了攻击者对时间信息的利用，他们采用2种模式，跳过不必要的缓存清除操作，实现不到7%的性能开销；为了降低性能开销，Godfrey等人[61]在虚拟机调度器发生内容切换的时候进行清除，新字段将添加到VCPU，以指示当前缓存数据的拥有者，而切换到空闲或相同的域时则不会发生缓存刷新.

修改用户程序以缓解“漏洞”，无疑会增加用户程序的开发周期和开发成本，而编译器辅助技术(compiler-assist)则可以极大地提高开发效率，实现对缓存侧信道攻击的防御.Crane等人[62]采用“移动目标防御”的防御理念，把一个代码编译为多个版本，各个版本的不同在于插入了不同数目的空操作、函数位置、寄存器随机化、指令替换等.程序在执行过程中动态选择执行路径，从而产生不同的结果，扰乱攻击者对信息的探测，实现缓存侧信道防御.Khan等人[63]开发了一个编译器辅助调度程序Biscuit,它可以非常高精度地检测到针对多租户服务器场中调度进程的基于缓存的侧通道攻击.用户以6%的性能为代价，可以实现对Flush+Flush,Flush+Reload,Prime+Probe等主流攻击方式的防御.

2.3 降低测量精准度

攻击者在实施微架构侧信道攻击时，需要获取到用户程序的执行情况、用户程序的内存访问模式后才能完成后续的攻击，而攻击者获取信息的精准度直接影响攻击的效果甚至攻击的成功与否.

目前的防御手段主要通过操作系统、虚拟机管理程序以及设计新型安全缓存架构提高映射关系的不确定性，降低资源共享的概率，从而降低攻击者对用户访问模式的获取精准度，提高系统的安全性，实现对缓存侧信道的防御.

2.3.1 干扰信息获取

表4展示了从操作系统(operating system, OS)和虚拟机管理程序(virtual machine manager, VMM)的角度降低攻击者测量精度的相关研究工作，并比较了不同防御措施需要修改的层次结构.

对于虚拟机管理程序而言，StealthMem[64]为每个处理器核管理一组锁定的Cache line，这些Cache line不会被驱逐，每个虚拟机可以把自己的敏感数据加载到锁定的Cache line中，使其对其他的虚拟机不可见.Han等人[65]则从虚拟机分配的角度出发，提出PSSF虚拟机分配策略.随后，Jia等人[66]从运行的主机数量和CPU利用率角度进行优化，减少能耗，攻击效率和攻击范围表明，采用合适的虚拟机分配策略可以有效降低虚拟机共存的攻击的成功率.刘维杰[70]提出一个全局的动态时钟模糊方案，利用最新的硬件虚拟化扩展技术，提供一个轻量级和动态的环境，使系统范围内的侧信道危害得到缓解.

除了虚拟机管理程序，相关研究表明也可以从操作系统的角度提供安全防御.Zhou等人[67]提出了CacheBar，采用新的复制访问管理模式对多用户的物理内存页进行管理，同时，设计了一种动态可维护的内存页面队列管理机制避免攻击者对缓存的恶意探.Sprabery等人[68]则认为，全部隔离用户页面会造成存储上的浪费，因此他们从侧信道的根源入手，把程序划分为多个安全隔离区域和正常区域，允许同一个安全域内的用户共享内存页，当用户在不同的安全域进行切换的时候，对硬件的状态进行清除.更进一步地，Nomani等人[69]使用HPC预测出程序的下一个执行阶段，并通过操作系统的调度，把预测出相同程序阶段的应用调度到不同的处理器核上，通过动态调度避免底层硬件结构的争用，缓解侧信道攻击的影响.

操作系统方面对内存进行防护很多时候需要硬件的支持，才能够在开销尽可能小的情况下完成.Ge等人[71]对现有的主流处理器进行分析，研究表明现有的结构不能支撑软件的防护.他们呼吁处理器厂商对现有的指令集进行安全扩充，并从5个方面对安全扩充指令集进行建议，以便于从操作系统等方面提供安全防护.

除了通过操作系统或虚拟机管理程序的调度外，还可以通过增加噪声的方式，干扰用户对信息的“监听”过程.Wang等人[72]利用DRAM更新作为噪声源，设计了MemJam架构，以较小的代价避免攻击者通过共享内存控制器“监听”用户程序的内存访问情况.

2.3.2 新型安全架构

使用硬件手段改变增加攻击者获取信息的难度，可以扰乱攻击者获取由于用户操作而对微架构状态产生的影响.表5列举了近几年的新型Cache架构，并从新型缓存架构设计方案、安全性、开销等方面对相关工作进行比较.

一种增加攻击者获取有效信息的缓存设计方案是通过隔离手段，即虽然攻击者与用户仍然共享缓存，但却使用不同的缓存块，从而避免攻击者判断用户程序的内存访问情况.Wang等人[73]提出了PLCache设计方案，在原有的缓存架构中增加Lock和ID位，并且软件程序员在程序运行时，可以通过操作系统把某个具体的缓存块锁定，当程序执行结束后再解除锁定；锁定的方式虽然可以提高安全性，但是会导致缓存利用率降低，针对这个问题，Domnitser等人[74]提出NoMo Cache架构，为所有正在运行的进程在对应的每个缓存集中预留Y个Cache line，通过对进程预留Cache line的方式对安全性和性能进行权衡，尽可能避免侧信道的攻击.

此外，很多人开始探索采用动态分隔的方式[87-88]提高安全性.如果动态分隔策略依赖于程序运行状态时，仍然会产生侧信道的风险，Wang等人[75]提供了一种安全的动态高速缓存分区方案，根据应用的不同安全等级进行分类，在提高缓存性能的同时，满足了分层安全的策略需求，与静态分区的方式相比，这种动态隔离的方式可以平均提升12.5%的性能.Werner等人[76]提出ScatterCache架构，使用关键字映射的方式实现偏置相联缓存，并对不同的安全域进行区分，使共享缓存的行为变得不可预测，实现对基于缓存侧信道的防御.

针对共享内存控制器的攻击，Wang等人[89]根据传统内存控制器的特点，分析攻击者对内存控制器的利用方式，根据用户安全域的不同，设计了一种基于静态时间隙的内存控制器队列调度算法，避免了攻击者对用户信息的探测.

2) 动态映射架构

除了静态和动态分隔的方案之外，还可以通过随机映射的方案，扰乱攻击者对用户信息的判断，实现对缓存侧信道攻击的防御.

Wang等人[73]设计了RPCache架构，使用一个重映射表实现第一级数据缓存Cache与内存映射的随机性，降低攻击者对用户访问数据的探测精度.文献[77]分析Prime+Probe在指令缓存上的实现方式，通过SVM(support vector machine)分类矩阵对使用随机映射策略的指令缓存的缓存踪迹进行定量分析，并实现了对第一级指令缓存的随机映射方案.更进一步地，NewCache[78]提供了一种随机映射的方法，使用CAM作为动态行号映射器，把原来的直接映射缓存的固定地址译码器替换为动态行号映射器，扰乱了攻击者对Cache line访问情况的探测，并使用65-nm CMOS工艺对原型系统进行验证.

虽然采用映射表的方式可以提高对侧信道攻击的抵抗能力，但是采用查找表的方式会受到存储代价的限制，导致其只能应用于较小的缓存.针对这个问题，Qureshi[79]设计了CEASE架构，如图3所示.在访问缓存时，采用低延时加密 width=5,height=17,dpi=110

解密模块(LLBC)，而对除缓存外的其他模块则是透明的，用较小的代价实现了对缓存侧信道的防御，同时又将随机映射的方式扩展到最后一级缓存.

为了避免静态密钥被攻击者探测，Qureshi[80]在CEASE的基础上，对LLBC的加密密钥不断改变，即CEASER架构，进一步提升系统鲁棒性.算法的重映射速率会影响对缓存侧信道的防御效果.但是，他们发现，通过修改查找冲突域的收缩算法，或者根据处理器的缓存替换算法，能够有效地缩短攻击者查找冲突域的时间，因此采用偏置映射的方式，把原有的CEASER改进为CEASER-S，把高速缓存分为多个区，不同的区中使用不同的Hash函数进行映射，把同一缓存集中的数据映射到不同的位置.随后，Ramkrishnan等人[81]发现CEASER-S架构使用二分查找攻击方式，同样可以把搜寻SCG的时间复杂度变为O(N)，因此他们使用间接查找表的方式实现“高偏置”和“高刷新率”，对基于冲突的缓存侧信道攻击实现防御.

当对整个LLC进行随机映射时，性能损耗较大，且重映射的方式会增加对内存的访问延时和缓存缺失的概率.Tan等人[82]认为并不需要对整体进行随机化映射，提出PhantomCache的局部随机化的缓存架构，以0.5%的性能下降，在保证随机化的同时，也实现了对微架构侧信道攻击的防御.

3) 缓存替换策略

根据缓存的工作原理，当用户访问的数据不在缓存中时，需要从内存中读取并写到缓存中，攻击者在攻击中，也需要依赖这一条件.Liu等人[83]提出了一种随机换入Cache的结构，这种架构的基本原理是当发生Cache miss时，把从内存中获取到的数据发送给CPU，但并不把这个数据保留到缓存，而是把这个数据“附近”的值填入到缓存中，在保证局部性的同时实现安全防御.Yan等人[84]发现当攻击者在多核处理器上开展侧信道攻击时，会存在“包容性受害缓存”(inclusive victim)，攻击者需要利用“包容性受害缓存”获取信息，因此，他们提出通过采用新的缓存块的替换策略SHARP，避免攻击者通过“inclusive victim”获取到用户的有用信息，从而实现安全防御.

4) 动态缓存架构

攻击者对块的大小、关联度、缓存替换算法、内存到缓存的映射函数等缓存架构信息掌握得越少，攻击的难度越高，攻击效果越差.因此，Bandara等人[85]从这个角度出发，通过动态改变缓存块的大小、缓存的相关联度以及缓存的大小，设计了自适应缓存架构.实验表明，在运行过程中动态改变缓存参数，最多可以降低90%的攻击精度；Dai等人[86]根据具体应用设计了多种不同缓存结构，并在运行过程中不断改变缓存配置，使攻击者无法采集到足够的信息，从而避免缓存侧信道攻击.

2.4 防御方法总结

如表6所示，软件检测的防御方式不需要改变现有的操作系统、硬件结构，只需在程序发布时对应用进行检测或用户在本地进行检测，部署方式最为灵活便捷.但是检测攻击的精准度、覆盖率、检测速度以及扩展性会直接影响检测工具在实际过程中的使用.

使用软件方式对代码进行修正，缓解“侧信道漏洞”同样不需要改变操作系统等，只需要采用“恒定时间技术”或“加入噪声”等手段就可以完成防御.但是，一方面，开发人员在设计时还需要考虑“恒定时间”等问题，增加了开发的周期和负担，同时验证代码的“恒定时间”也是一个很大的挑战；另一方面，对代码进行修正无疑会降低程序执行效率，影响程序性能.

从操作系统(OS)或虚拟机管理程序(VMM)的角度实现不同安全域之间的隔离，增加攻击者获取信息的精准度，或者改变虚拟机的分配策略，实现对缓存侧信道攻击的防御，但是管理粒度相对较粗，增大操作系统的负担，还有可能需要硬件的支持.

缓存侧信道攻击中，攻击者是利用硬件结构的特点开展攻击，而新型安全缓存架构设计直接影响了缓存侧信道攻击中获取信息的途径，可以有效阻止缓存侧信道攻击，且对操作系统、用户程序等的要求相对较小，对用户程序的性能影响也最小，因此受到了越来越多的研究和关注.但是这种方式需要硬件的更新和硬件厂商的支持，因此部署周期相对较长.

3 防御面临的挑战

随着越来越多的基于处理器的硬件攻击方式的出现，学术界和厂商在研究如何能够提高处理器的性能和降低处理器功耗的同时，也开始对处理器的安全性进行考虑.基于微架构的侧信道攻击属于侧信道攻击的一种，严重威胁了用户的信息安全，与传统的侧信道攻击不同的是，微架构侧信道攻击利用处理器中的微架构状态传递信息，打破了操作系统等提供的安全隔离，攻击者可以通过运行于同一硬件结构上的进程“窃取”用户信息，造成密钥等信息泄露；攻击者的攻击范围包括运行于同一个实体设备的进程，也可以包括云环境共享硬件结构的不同租户；攻击者可以通过直接操作，也可以通过远程操作完成攻击.未来缓存侧信道的研究主要有3个方面：

1) 定位缓存侧信道漏洞

在防御方面，硬件的更新迭代周期比较长，更新的代价较大，利用软件实现对侧信道的防御措施可以以最快的速度完成部署，但是使用软件进行防护时，或者在对即将发布程序的安全性进行验证时，需要知道软件中是否存在侧信道漏洞以及侧信道漏洞的位置.

CacheS[47],DATA[46],CacheAudit[40],CacheD[45]等工具可以对软件进行分析，检测程序中是否有可能遭受被基于缓存的侧信道攻击，以及程序的哪些位置可能遭受这种攻击，另一方面，攻击者也可以利用发现的漏洞对用户程序开展攻击.但是，作为一种与处理器硬件紧密相关的攻击方式，在分析程序是否存在“微架构侧信道漏洞”时，需要对硬件平台以及缓存结构进行考虑，而不能仅从软件的角度对程序进行分析.

在对缓存侧信道漏洞进行分析时，需要兼顾缓存替换算法、缓存块大小、缓存组相连度等缓存架构参数的硬件模型描述缓存行为，才能较为准确地判断出程序中是否存在“缓存侧信道漏洞”.程序在真实环境中运行时，硬件结构的不同、指令集的不同，操作系统的不同都会对“缓存侧信道漏洞”的判断产生影响.此外在使用各种攻击分析定位程序中的漏洞时，仍会存在代码覆盖率、检测时间、检测结果解释性等问题.如何保证分析工具的结果与程序在真实环境下运行的结果相同，也是一个急需解决的问题.

2) 动态缓存架构设计

在缓存侧信道攻击中，攻击者需要通过缓存获取出用户的内存访问模式，再通过其他先验知识对用户内存访问模式进行分析，就可以得到用户信息.因此，设计一个新的缓存架构，避免攻击者获取用户内存访问模式，可以有效地对缓存侧信道攻击进行防御.在基于冲突的攻击中，攻击者需要使用冲突域填充缓存，把缓存初始化到攻击者已知的某个状态；同时攻击者也需要冲突域获取缓存的状态变化，从而对用户对缓存的访问情况进行“监听”.攻击者需要一个比较小的冲突域，称为SCG来保证攻击的精度和速度.

Vila等人[36]首次系统地对“冲突域”进行研究，把查找算法的复杂度从O(N2)变为O(a2N).随后，Song等人[37]从理论上对该查找算法进行分析，认为当对分隔参数进行设置后，算法的复杂度应为O(aN).此外，Qureshi[80]和Ramkrishnan等人[81]分别根据Cache结构特点设计了线性复杂度的查找算法，这无疑增加了攻击者的攻击速度.静态的Cache访问模式的固定化给攻击者以可乘之机，因此设计一个动态变化的缓存结构能够提高对缓存侧信道攻击的防御，增加攻击者寻找“冲突域”的复杂度.CEASER及CEASER-S等工作实现了一个密钥周期性变化的缓存映射方案，以一个较小的代价实现了动态缓存结构，但是Bodduna等人[90]认为由于CEASER方案中LLBC采用线性加密算法，切换密钥对防御效果没有增益，而采用查找表的方式又会面临内存开销太大的问题，一种兼顾性能和动态随机映射效果的加密算法仍是一个公开的难题.

3) Cache架构安全性评估

目前，设计新的安全缓存架构、改变缓存的替换算法、缓存的预取方式等从缓存角度增加了攻击者对内存访问模式的“监听”精准度.但是目前大多数硬件结构是闭源的，且各自的研究中没有一个统一的安全评价标准，因此对目前的Cache结构安全性的比较就成为一个比较困难的问题.Helft[91]从冲突域的角度开发了一个用于分析微架构安全性的模拟器，对缓存架构的不同参数进行分析，讨论Cache架构对“冲突域”查找算法的影响.Deng等人[92]建立“3步分析模型”，并分析了18种Cache的安全架构，讨论不同的缓存设计对可能的缓存侧信道攻击的防御效果.He等人[6]使用信息流(information flow)对Cache结构的安全性进行分析.这些研究内容都对Cache结构进行安全性分析，但是，统一的度量标准和缓存、攻击以及软件执行的形式化建模仍然是一个尚未解决的问题.

4 总结

基于缓存的侧信道攻击由于其高隐蔽性、高传输速度、可开展远程攻击等特点，打破了由软件和操作系统提供的隔离机制，造成用户信息泄露，引起了学术界和工业界的广泛关注.本文从攻击步骤的角度对基于缓存的侧信道攻击进行系统描述，把攻击的步骤分为：确定“漏洞”、确定“冲突域”、获取内存访问模式信息、还原信息等，并根据这些步骤对攻击方式进行分析，对各个步骤所需要解决的问题以及面临的挑战进行总结.之后，我们按照攻击模型对防御手段把防御分为代码检测、缓解“漏洞”、降低信息获取精准度等不同阶段，并对不同阶段的防御手段进行分析比较，我们发现动态修改缓存内数据分布的方式可以以一个较低的性能代价对缓存侧信道攻击实现有效防御.最后讨论了缓存侧信道防御面临的主要挑战以及未来的研究方向.

[1]Kocher P, Horn J, Fogh A, et al. Spectre attacks: Exploiting speculative execution[C] //Proc of 2019 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2019: 1-19

[2]Lipp M, Schwarz M, Gruss D, et al. Meltdown: Reading kernel memory from user space[C] //Proc of the 27th USENIX Security Symp. Berkeley, CA: USENIX Association, 2018: 973-990

[3]Van Bulck J, Minkin M, Weisse O, et al. Foreshadow: Extracting the keys to the Intel SGX kingdom with transient out-of-order execution[C] //Proc of the 27th USENIX Security Symp. Berkeley, CA: USENIX Association, 2018: 991-1008

[4]Schwarz M, Lipp M, Moghimi D, et al. ZombieLoad: Cross-privilege-boundary data sampling[C] //Proc of the 2019 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2019: 753-768

[5]Ge Jingquan, Tu Chenyang, Gao Neng. Technology overview of side channel analysis[J]. Journal of Information Security Research, 2019, 5(1): 75-87 (in Chinese)(葛景全, 屠晨阳, 高能. 侧信道分析技术概览与实例[J]. 信息安全研究, 2019, 5(1): 75-87)

[6]He Zecheng, Lee R B. How secure is your cache against side-channel attacks[C] //Proc of the 50th Annual IEEE/ACM Int Symp on Microarchitecture. New York: ACM, 2017: 341-353

[7]Kayaalp M, Abu-Ghazaleh N, Ponomarev D, et al. A high-resolution side-channel attack on last-level cache[C] //Proc of the 53rd DAC Annual Design Automation Conf. New York: ACM, 2016: 72:1-72:6

[8]Osvik D A, Shamir A, Tromer E. Cache attacks and countermeasures:The case of AES[C] //Proc of the Cryptographer’s Track at the RSA Conf. Berlin: Springer, 2006: 1-20

[9]Ristenpart T, Tromer E, Shacham H, et al. Hey, you, get off of my cloud: Exploring information leakage in third-party compute clouds[C] //Proc of the 16th ACM Conf on Computer and Communications Security. New York: ACM, 2009: 199-212

[10]Yarom Y, Falkner K. Flush+Reload: A high resolution, low noise, L3 cache side-channel attack[C] //Proc of the 23rd USENIX Security Symp. Berkeley, CA: USENIX Association, 2014: 719-732

[11]Gruss D, Maurice C, Wagner K, et al. Flush+ Flush: A fast and stealthy cache attack[C] //Proc of the Int Conf on Detection of Intrusions and Malware, and Vulnerability Assessment. Berlin: Springer, 2016: 279-299

[12]Gallais J F, Kizhvatov I, Tunstall M. Improved trace-driven cache-collision attacks against embedded AES implementa-tions[C] //Proc of the Int Workshop on Information Security Applications. Berlin: Springer, 2010: 243-257

[13]Gruss D, Spreitzer R, Mangard S. Cache template attacks: Automating attacks on inclusive last-level caches[C] //Proc of the 24th USENIX Security Symp. Berkeley, CA: USENIX Association, 2015: 897-912

[14]Liu Fangfei, Yarom Y, Ge Qian, et al. Last-level cache side-channel attacks are practical[C] //Proc of the 2015 IEEE Symp on Security and Privacy. Los Alamitos, CA: IEEE Computer Security, 2015: 605-622

[15]Irazoqui G, Eisenbarth T, Sunar B. Cross processor cache attacks[C] //Proc of the 11th ACM on Asia Conf on Computer and Communications Security. New York: ACM, 2016: 353-364

[16]Gülmezogˇlu B, Inci M S, Irazoqui G, et al. A faster and more realistic flush+ reload attack on AES[C] //Proc of the Int Workshop on Constructive Side-Channel Analysis and Secure Design. Berlin: Springer, 2015: 111-126

[17]Aly H, ElGayyar M. Attacking aes using Bernstein’s attack on modern processors[C] //Proc of the Int Conf on Cryptology in Africa. Berlin: Springer, 2013: 127-139

[18]Briongos S, Malagón P, de Goyeneche J M, et al. Cache misses and the recovery of the full AES 256 key[J]. Applied Sciences, 2019, 9(5): 944-967

[19]Gullasch D, Bangerter E, Krenn S. Cache games--Bringing access-based cache attacks on AES to practice[C] //Proc of the 2011 IEEE Symp on Security and Privacy. Los Alamitos, CA: IEEE Computer Security, 2011: 490-505

[20]Genkin D, Valenta L, Yarom Y. May the fourth be with you: A microarchitectural side channel attack on several real-world applications of curve25519[C] //Proc of the 2017 ACM SIGSAC Conf on Computer and Communications Security.New York: ACM, 2017: 845-858

[21]Disselkoen C, Kohlbrenner D, Porter L, et al. Prime+ abort: A timer-free high-precision L3 cache attack using Intel TSX [C] //Proc of the 26th USENIX Security Symp. Berkeley, CA: USENIX Association, 2017: 51-67

[22]Lipp M, Gruss D, Spreitzer R, et al. Armageddon: Cache attacks on mobile devices[C] //Proc of the 25th USENIX Security Symp. Berkeley, CA: USENIX Association, 2016: 549-564

[23]Guanciale R, Nemati H, Baumann C, et al. Cache storage channels: Alias-driven attacks and verified countermeasures[C] //Proc of the 2016 IEEE Symp on Security and Privacy. Los Alamitos, CA: IEEE Computer Security, 2016: 38-55

[24]Hund R, Willems C, Holz T. Practical timing side channel attacks against kernel space ASLR[C] //Proc of the 2013 IEEE Symp on Security and Privacy. Los Alamitos, CA: IEEE Computer Security, 2013: 191-205

[25]Van Schaik S, Giuffrida C, Bos H, et al. Malicious management unit: Why stopping cache attacks in software is harder than you think[C] //Proc of the 27th USENIX Security Symp. Berkeley, CA: USENIX Association, 2018: 937-954

[26]Gras B, Razavi K, Bos H, et al. Translation leak-aside buffer: Defeating cache side-channel protections with TLB attacks[C] //Proc of the 27th USENIX Security Symp. Berkeley, CA: USENIX Association, 2018: 955-972

[27]Wu Zhengyu, Xu Zhang, Wang Haining. Whispers in the hyper-space: High-bandwidth and reliable covert channel attacks inside the cloud[J]. IEEE/ACM Transactions on Networking, 2014, 23(2): 603-615

[28]Szefer J. Survey of microarchitectural side and covert channels, attacks, and defenses[J]. Journal of Hardware and Systems Security, 2019, 3(3): 219-234

[29]Ge Qian, Yarom Y, Cock D, et al. A survey of microarchi-tectural timing attacks and countermeasures on contemporary hardware[J]. Journal of Cryptographic Engineering, 2018, 8(1): 1-27

[30]Lyu Y, Mishra P. A survey of side-channel attacks on caches and countermeasures[J]. Journal of Hardware and Systems Security, 2018, 2(1): 33-50

[31]Zhang Xiaokuan, Xiao Yuan, Zhang Yinqian. Return-oriented flush-reload side channels on arm and their implications for Android devices[C] //Proc of the 2016 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2016: 858-870

[32]Miao Xinliang, Jiang Liehui, Chang Rui. Survey of access driven cache-based side channel attack[J]. Journal of Computer Research and Development, 2020, 57(4): 824-835 (in Chinese)(苗新亮, 蒋烈辉, 常瑞. 访问驱动下的 Cache 侧信道攻击研究综述[J]. 计算机研究与发展, 2020, 57(4): 824-835)

[33]Gülmezogˇlu B, Inci M S, Irazoqui G, et al. A faster and more realistic flush + reload attack on AES[C] //Proc of the Int Workshop on Constructive Side-Channel Analysis and Secure Design. Berlin: Springer, 2015: 111-126

[34]Liang Xin, Gui Xiaolin, Dai Huijun, et al. Cross-VM cache side channel attacks in cloud: A survey[J]. Chinese Journal of Computers, 2017, 40(2): 317-336 (in Chinese)(梁鑫, 桂小林, 戴慧珺, 等. 云环境中跨虚拟机的Cache侧信道攻击技术研究[J]. 计算机学报, 2017, 40(2): 317-336)

[35]Wang Yao, Ferraiuolo A, Suh G E. Timing channel protection for a shared memory controller[C] //Proc of the 20th IEEE Int Symp on High Performance Computer Architecture (HPCA). Los Alamitos, CA: IEEE Computer Security, 2014: 225-236

[36]Vila P, Köpf B, Morales J F. Theory and practice of finding eviction sets[C] //Proc of the 2019 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2019: 39-54

[37]Song Wei, Liu Peng. Dynamically finding minimal eviction sets can be quicker than you think for side-channel attacks against the LLC[C] //Proc of the 22nd Int Symp on Research in Attacks, Intrusions and Defenses. Berkeley, CA: USENIX Association, 2019: 427-442

[38]Martin R, Demme J, Sethumadhavan S. TimeWarp: Rethinking timekeeping and performance monitoring mechanisms to mitigate side-channel attacks[C] //Proc of the 39th Annual Int Symp on Computer Architecture (ISCA). Los Alamitos, CA: IEEE Computer Security, 2012: 118-129

[39]Doychev G, Köpf B, Mauborgne L, et al. CacheAudit: A tool for the static analysis of cache side channels[J]. ACM Transactions on Information and System Security, 2015, 18(1):4:1-4:32

[40]Doychev G, Köpf B. Rigorous analysis of software countermeasures against cache attacks[J]. ACM SIGPLAN Notices, 2017, 52(6): 406-421

[41]Zankl A, Heyszl J, Sigl G. Automated detection of instruction cache leaks in modular exponentiation software[C] //Proc of the Int Conf on Smart Card Research and Advanced Applications. Berlin: Springer, 2016: 228-244

[42]Carré S, Facon A, Guilley S, et al. Cache-timing attack detection and prevention[C] //Proc of the Int Workshop on Constructive Side-Channel Analysis and Secure Design. Berlin: Springer, 2019: 13-21

[43]Irazoqui G, Cong Kai, Guo Xiaofei, et al. Did we learn from LLC side channel attacks? A cache leakage detection tool for crypto libraries[J]. arXiv preprint, arXiv:1709.01552, 2017

[44]Brotzman R, Liu Shen, Zhang Danfeng, et al. CaSym: Cache aware symbolic execution for side channel detection and mitigation[C] //Proc of the 2019 IEEE Symp on Security and Privacy. Piscataway, NJ: IEEE, 2019: 505-521

[45]Wang Shuai, Wang Pei, Liu Xiao, et al. CacheD: Identifying cache-based timing channels in production software[C] //Proc of the 26th USENIX Security Symp. Berkeley, CA: USENIX Association, 2017: 235-252

[46]Weiser S, Zankl A, Spreitzer R, et al. DATA—Differential address trace analysis: Finding address-based side-channels in binaries[C] //Proc of the 27th USENIX Security Symp. Berkeley, CA: USENIX Association, 2018: 603-620

[47]Wang Shuai, Bao Yuyan, Liu Xiao, et al. Identifying cache-based side channels through secret-augmented abstract interpretation[C] //Proc of the 28th USENIX Security Symp. Berkeley, CA: USENIX Association, 2019: 657-674

[48]Gridin I, García C P, Tuveri N, et al. Triggerflow: Regression testing by advanced execution path inspection[C] //Proc of the Int Conf on Detection of Intrusions and Malware, and Vulnerability Assessment. Berlin: Springer, 2019: 330-350

[49]Wichelmann J, Moghimi A, Eisenbarth T, et al. MicroWalk: A framework for finding side channels in binaries[C] //Proc of the 34th Annual Computer Security Applications Conf. New York: ACM, 2018: 161-173

[50]Oleksenko O, Trach B, Silberstein M, et al. SpecFuzz: Bringing spectre-type vulnerabilities to the surface[C] //Proc of the 29th USENIX Security Symp. Berkeley, CA: USENIX Association, 2020: 1481-1498

[51]Guo Shengjian, Chen Yue, Li Peng, et al. SpecuSym: Speculative symbolic execution for cache timing leak detection[J]. arXiv preprint, arXiv:1911.00507, 2019

[52]García C P, Brumley B B. Constant-time callees with variable-time callers[C] //Proc of the 26th USENIX Security Symp. Berkeley, CA: USENIX Association, 2017: 83-98

[53]Bernstein D J, Lange T, Schwabe P. The security impact of a new cryptographic library[C] //Proc of the Int Conf on Cryptology and Information Security in Latin America. Berlin: Springer, 2012: 159-176

[54]Andrysco M, Kohlbrenner D, Mowery K, et al. On subnormal floating point and abnormal timing[C] //Proc of the 2015 IEEE Symp on Security and Privacy. Los Alamitos, CA: IEEE Computer Security, 2015: 623-639

[55]Panda B. Fooling the sense of cross-core last-level cache eviction based attacker by prefetching common sense[C] //Proc of the 28th Int Conf on Parallel Architectures and Compilation Techniques. Piscataway, NJ: IEEE, 2019: 138-150

[56]Almeida J B, Barbosa M, Barthe G, et al. Verifying constant-time implementations[C] //Proc of the 25th USENIX Security Symp. Berkeley, CA: USENIX Association, 2016: 53-70

[57]Bond B, Hawblitzel C, Kapritsos M, et al. Vale: Verifying high-performance cryptographic assembly code[C] //Proc of the 26th USENIX Security Symp. Berkeley, CA: USENIX Association, 2017: 917-934

[58]Daniel L A, Bardin S, Rezk T. BINSEC/REL: Efficient relational symbolic execution for constant-time at binary-level[C] //Proc of the 2020 IEEE Symp on Security and Privacy (SP). Piscataway, NJ: IEEE, 2020: 1021-1038

[59]Mohammed A. Detecting non-constant time code in crypto-graphy libraries using a static information flow analysis[D]. Pennsylvania: The Pennsylvania State University, 2018

[60]Zhang Yinqian, Reiter M K. Düppel: Retrofitting commodity operating systems to mitigate cache side channels in the cloud[C] //Proc of the 2013 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2013: 827-838

[61]Godfrey M M, Zulkernine M. Preventing cache-based side-channel attacks in a cloud environment[J]. IEEE Transactions on Cloud Computing, 2014, 2(4): 395-408

[62]Crane S, Homescu A, Brunthaler S, et al.Thwarting cache side-channel attacks through dynamic software diversity[C] //Proc of the 2015 NDSS Symp. San Diego, CA: ISOC, 2015. DOI:10.14722/ndss.2015.23264

[63]Khan S, Mruru G, Pande S. A compiler assisted scheduler for detecting and mitigating cache-based side channel attacks[J]. arXiv preprint, arXiv:2003.03850, 2020

[64]Kim T, Peinado M, Mainar-Ruiz G. StealthMem: System-level protection against cache-based side channel attacks in the cloud[C] //Proc of the 21st USENIX Security Symp. Berkeley, CA: USENIX Association, 2012: 189-204

[65]Han Yi, Chan J, Alpcan T, et al. Using virtual machine allocation policies to defend against co-resident attacks in cloud computing[J]. IEEE Transactions on Dependable and Secure Computing, 2015, 14(1): 95-108

[66]Jia Hefei, Liu Xu, Di Xiaoqiang, et al. Security strategy for virtual machine allocation in cloud computing[J]. Procedia Computer Science, 2019,147(2): 140-144

[67]Zhou Ziqiao, Reiter M K, Zhang Yinqian. A software approach to defeating side channels in last-level caches[C] //Proc of the 2016 ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2016: 871-882

[68]Sprabery R, Evchenko K, Raj A, et al. Scheduling, isolation, and cache allocation: A side-channel defense[C] //Proc of the 2018 IEEE Int Conf on Cloud Engineering. Piscataway, NJ: IEEE, 2018: 34-40

[69]Nomani J, Szefer J. Predicting program phases and defending against side-channel attacks using hardware performance counters[C] //Proc of the 4th Workshop on Hardware and Architectural Support for Security and Privacy. New York: ACM, 2015: 9:1-9:4

[70]Liu Weijie. Research on cross-VM side channel attack, detection and defense in cloud environment[D]. Wuhan: Wuhan University, 2018 (in Chinese)(刘维杰. 云计算环境下跨虚拟机侧信道的攻击, 检测与防御[D]. 武汉: 武汉大学, 2018)

[71]Ge Qian, Yarom Y, Heiser G. No security without time protection: We need a new hardware-software contract[C] //Proc of the 9th Asia-Pacific Workshop on Systems. New York: ACM, 2018: 1:1-1:9

[72]Wang Ying, Li Wen, Li Huawei, et al. Lightweight timing channel protection for shared DRAM controller[C] //Proc of the 2018 IEEE Int Test Conf. Piscataway, NJ: IEEE, 2018: 1-10

[73]Wang Zhenghong, Lee R B. New cache designs for thwarting software cache-based side channel attacks[J]. ACM SIGARCH Computer Architecture News, 2007, 35(2): 494-505

[74]Domnitser L, Jaleel A, Loew J, et al. Non-monopolizable caches: Low-complexity mitigation of cache side channel attacks[J]. ACM Transactions on Architecture and Code Optimization, 2012, 8(4): 35:1-35:21

[75]Wang Yao, Ferraiuolo A, Zhang Danfeng, et al. SecDCP: Secure dynamic cache partitioning for efficient timing channel protection[C] //Proc of the 53rd Annual Design Automation Conf. New York: ACM, 2016: 74:1-74:6

[76]Werner M, Unterluggauer T, Giner L, et al. ScatterCache: Thwarting cache attacks via cache set randomization[C] //Proc of the 28th USENIX Security Symp. Berkeley, CA: USENIX Association, 2019: 675-692

[77]Liu Fangfei, Wu Hao, Lee R B. Can randomized mapping secure instruction caches from side-channel attacks[C] //Proc of the 4th Workshop on Hardware and Architectural Support for Security and Privacy. New York: ACM, 2015: 4:1-4:8

[78]Liu Fangfei, Wu Hao, Mai K, et al. NewCache: Secure cache architecture thwarting cache side-channel attacks[J]. IEEE Micro, 2016, 36(5): 8-16

[79]Qureshi M K. CEASER: Mitigating conflict-based cache attacks via encrypted-address and remapping[C] //Proc of the 51st Annual IEEE/ACM Int Symp on Microarchitecture. Los Alamitos, CA: IEEE Computer Security, 2018: 775-787

[80]Qureshi M K. New attacks and defense for encrypted-address cache[C] //Proc of the 46th Int Symp on Computer Architecture. New York: ACM, 2019: 360-371

[81]Ramkrishnan K, Zhai A, McCamant S, et al. New attacks and defenses for randomized caches[J]. arXiv preprint, arXiv:1909.12302, 2019

[82]Tan Qinhan, Zeng Zhihua, Bu Kai, et al. PhantomCache: Obfuscating cache conflicts with localized randomization[C] //Proc of the 2020 NDSS Symp. San Diego, CA: ISOC, 2020. DOI:10.14722/ndss.2020.24086

[83]Liu Fangfei, Lee R B. Random fill cache architecture[C] //Proc of the 47th Annual IEEE/ACM Int Symp on Microarchi-tecture. Los Alamitos, CA: IEEE Computer Society, 2014: 203-215

[84]Yan Mengjia, Gopireddy B, Shull T, et al. Secure hierarchy-aware cache replacement policy (SHARP): Defending against cache-based side channel attacks[C] //Proc of the 44th Annual Int Symp on Computer Architecture. New York: ACM, 2017: 347-360

[85]Bandara S, Kinsy M A. Adaptive caches as a defense mechanism against cache side-channel attacks[C] //Proc of the 3rd ACM Workshop on Attacks and Solutions in Hardware Security Workshop. New York: ACM, 2019: 55-64

[86]Dai Chenxi, Adegbija T. Exploiting configurability as a defense against cache side channel attacks[C] //Proc of the 2017 IEEE Computer Society Annual Symp on VLSI. Los Alamitos, CA: IEEE Computer Society, 2017: 495-500

[87]Sanchez D, Kozyrakis C. Vantage: Scalable and efficient fine-grain cache partitioning[C] //Proc of the 38th Annual Int Symp on Computer Architecture. New York: ACM, 2011: 57-68

[88]Xie Yuejian, Loh G H. PIPP: Promotion/insertion pseudo-partitioning of multi-core shared caches[J]. ACM SIGARCH Computer Architecture News, 2009, 37(3): 174-183

[89]Wang Yao, Ferraiuolo A, Suh G E. Timing channel protection for a shared memory controller[C] //Proc of the 20th IEEE Int Symp on High Performance Computer Architecture. Los Alamitos, CA: IEEE Computer Security, 2014: 225-236

[90]Bodduna R, Ganesan V, Slpsk P, et al. BRUTUS: Refuting the security claims of the cache timing randomization countermeasure proposed in CEASER[J]. IEEE Computer Architecture Letters, 2020, 19(1): 9-12

[91]Helft P P. Microarchitecture simulation for security[D]. Madrid: Polytechnic University of Madrid, 2018

[92]Deng Shuwen, Xiong Wenjie, Szefer J. Analysis of secure caches using a three-step model for timing-based attacks[J]. Journal of Hardware and Systems Security, 2019, 3(4): 397-425