exLCL:一种针对spectre攻击的防御方法
王少清1, 赵有健1,2, 吕志远1    
1. 清华大学 计算机科学与技术系, 北京 100084;
2. 鹏城实验室, 深圳 518000
摘要:新近发现的spectre攻击对计算机安全提出了严峻挑战。该攻击利用处理器推测执行过程中留下的不可消除的微架构(如缓存)状态变化,结合侧信道技术,泄露私密数据。该文首先研究spectre攻击的指令执行流程,提出阶段模型并深入分析利用漏洞所需满足的竞争条件,随后提出一种旨在避免攻击者满足竞争条件的防御方案,即exLCL。基于gem5的模拟实验证明了exLCL的有效性和可行性。与现有防御方案相比,exLCL处理逻辑更简单。
关键词spectre攻击    侧信道    阶段模型    缓存访问时延    
exLCL for defense against spectre attacks
WANG Shaoqing1, ZHAO Youjian1,2, LÜ Zhiyuan1    
1. Department of Computer Science and Technology, Tsinghua University, Beijing 100084, China;
2. Peng Cheng Laboratory, Shenzhen 518000, China
Abstract: The newly discovered spectre attack poses severe challenges to computer security. The attacker leaks secret data by exploiting the indelible micro-architecture (such as cache) state changes left by speculative execution commands combined with the cache side channels. This paper first describes the instruction execution process of the spectre attack, presents a stage model for the attack, and identifies the competition conditions when a vulnerability can be exploited. Then, a defense entitled exLCL (extended L1 cache latency) is presented for preventing an attacker from meeting the competition conditions. Simulations based on gem5 show the effectiveness and feasibility of the exLCL defense which has simpler logic than existing defenses.
Key words: spectre attack    side channels    stage model    cache latency    

为提高性能,现代处理器通常引入乱序执行和推测执行等优化机制。乱序执行是指处理器不按照程序顺序执行指令,而是并行地处理数据互不依赖的指令。推测执行是指处理器不等待分支指令的最终执行结果,而是猜测最有可能的结果并按该结果对应的分支路径处理后续指令。然而,追求处理器性能最大化的同时往往伴随着安全漏洞。例如,近期公开的spectre[1]和meltdown[2]攻击展示了攻击者如何利用现代处理器的推测执行和乱序执行机制,诱导处理器以程序员或编译器不希望的方式执行部分指令(通常称为瞬态执行),建立侧信道来泄露私密数据,从而破坏程序原有的安全特性。更严重的是,研究者针对此类硬件缺陷,挖掘出越来越多的攻击方法,攻击范围涵盖各类主流处理器、操作系统和云平台等[3-7]。由于此类攻击易导致严重的数据泄露等问题,工业界和学术界陆续提出了多种基于软件和硬件的防御方案[8-14]

与此同时,针对层出不穷的攻击和防御方案,有研究者开始深入分析此类攻击所利用的漏洞,对攻击过程进行建模,甚至量化评估攻击成效。这方面的典型研究有:Xiao等[15]提出SPEECHMINER软件框架,该框架可以半自动化地探索和测量推测执行侧信道漏洞,即量化分析某一漏洞的可利用性。具体而言,如果某一漏洞在SPEECHMINER测试下显示攻击不可利用,则可断言该漏洞不具有安全威胁。Canella等[16]将瞬态执行攻击抽象为6个阶段,即准备工作、触发瞬态执行、访问私密数据、编码私密数据、架构恢复、解码私密数据,并按该6阶段的划分,综合评估了现有的瞬态执行攻击类型和防御方案。上述研究工作深化了对此类漏洞的理解,对进一步探索攻击和防御手段具有重要意义。然而,上述工作中,SPEECHMINER关注的是类似meltdown的异常错误引起的漏洞,Canella等则是对meltdown和spectre攻击及防御的分类和评述,而目前专门针对spectre类型攻击的建模分析并建立基于分析结果的防御方案的研究还较少。

有鉴于此,本文针对spectre攻击提出阶段模型,深入分析可成功利用漏洞需满足的竞争条件,并据此提出了一种针对spectre攻击的防御方法——exLCL。由于spectre攻击与CPU指令执行过程紧密相关,而绝大部分处理器的具体实现细节属于商业机密,并未公开。针对此挑战,本文对漏洞利用过程进行必要的抽象,建立了漏洞利用模型,分析了模型与漏洞可利用性之间的关系(比如,在什么样的条件下漏洞不可利用)。在此基础上,设计实现漏洞不可利用的条件,即调整L1数据缓存的访问时延,从而防御spectre攻击。在gem5模拟器上对exLCL进行安全性和性能评估,SPLASH-2和SPEC CPU2006等基准测试程序的运行结果证明了所提方案的可行性和有效性。

1 研究背景 1.1 处理器指令执行流程

虽然处理器具体的内部实现均属各大公司的知识产权,是非公开的,但基本的指令执行流程一般分为取指(instruction fetch)、译码(decode)、发射(issue)、执行(execute,包括访问存储系统)及退出(retire) 5个步骤[15],如图 1所示。处理器指令执行前端包括取指和译码。在取指阶段,处理器首先从L1指令缓存中取出待执行的指令,如果缓存失效,则需要进一步访问存储子系统(如L3缓存、内存等)。在译码阶段,指令译码器将复杂指令翻译成更简单的微操作(μOP)。随后进入指令执行后端,此部分包括发射、执行和退出。在发射阶段,一旦微操作成功发射,它们将不再受程序顺序所限,而是可以乱序执行,由重排缓冲区负责记录跟踪所有微操作。在执行阶段,微操作被转发至调度器,并在合适的执行单元中进行诸如算术逻辑运算、读写存储等。在退出阶段,当一条指令顺利执行完成后,重排缓冲区负责将所有运行结果按程序顺序提交。换言之,指令执行阶段可以乱序执行,但退出阶段必须按序提交结果。现代处理器大多引入分支预测机制。以条件分支为例,分支预测器在判断条件结果出来前,会根据过往分支结果,预测当前最有可能的分支路径,并按该路径继续执行后续指令。若预测错误,处理器回滚此前按错误路径执行的操作,并且程序员感知不到此次错误操作(然而,某些微结构状态,如缓存状态,通常不会被还原。本文所述攻击正是利用该原理)。反之,若预测正确,处理器将获得性能提升。

图 1 x86指令执行模型(以Intel的skylake处理器为例)

1.2 缓存侧信道攻击

缓存是为了弥补处理器和内存速度差异而引入的结构。典型的Intel x86处理器共有3级缓存,其中L1缓存分为L1数据缓存和L1指令缓存,L2缓存是一个包含数据和指令的统一缓存。L1和L2属于CPU核心私有。L3缓存(又称LLC缓存)被分割成片,并在CPU的所有核心之间共享。访问速度上,L1最快,L3最慢。

侧信道攻击[17]是指攻击者不直接攻击某一系统,而是根据系统运行时产生的可观测的副作用,推断处理数据,达到获取私密数据的目的。例如,攻击者根据加密运算中泄露的物理状态信息(如功耗、运行时间等),分析破译对应的密钥。

缓存侧信道攻击是指攻击者利用缓存访问时间的差异(缓存命中和失效对应的访问时间有差别),推测缓存中的信息,从而获得私密数据。近年来,研究者提出了许多基于缓存的攻击方法,典型的有Evict+Time[18]、Prime+Probe[19]和Flush+Reload[20]。比如,Flush+Reload攻击利用共享的LLC缓存,频繁使用clflush指令刷新目标缓存,通过测量重新加载数据所需的时间,攻击者可以确定在此期间其他进程是否将数据加载到缓存中,从而还原出该数据。

1.3 spectre攻击

2017年,学术界和工业界的安全研究人员发现了spectre攻击漏洞,旋即引发了广泛的震动。spectre攻击利用处理器推测执行过程中产生的微架构副作用,基于缓存侧信道技术,窃取受害者的私密数据。

发展至今,spectre攻击已经出现多种变体。例如,按推测执行所利用的微架构部件划分,有利用模式历史表(pattern history table,PHT)的spectre-PHT (v1,v1.1)[1, 21]、利用分支目标缓冲器(branch target buffer,BTB)的spectre-BTB (v2)[1]、利用返回堆栈缓冲(return stack buffer,RSB)的spectre-RSB (ret2spec)[4]和利用存储加载(store to load,STL)的spectre-STL (v4) [3]等。关于spectre攻击的详细综述,可以参考文[22]。

鉴于spectre攻击变体繁多,下面以spectre v1为例,分析具体攻击原理。图 2所示为攻击示例代码。对于条件分支,首先检查参数x是否越界。通常情况下,如果x超过array1的大小,程序将不会执行紧接着的对array2的读取;但如果越界检查需要花费的时间较长,处理器不会停下来等待检查结果,而是会根据分支预测部件给出的最有可能的结果,推测执行。于是漏洞出现了,如果攻击者能训练分支预测部件,始终给出x不超过array1大小的预测(实际x越界),那么攻击者将能绕过检查,越界访问私密数据。假设此时读取的array1[x]值正好是私密数据k,则访问array2[k×4 096]将造成缓存状态的改变,并且该改变是与k相关联的。如此一来,即便最终检查结果导致指令回滚,缓存状态的变化也不会被还原,这意味着攻击者可以利用基于缓存的侧信道攻击技术,分析出k的值。

图 2 (网络版彩图)spectre v1攻击示例代码

2 威胁模型

在spectre攻击的各种变体中,绕过边界检查的spectre v1对各平台和设备的影响最大,因此本文对spectre攻击形成条件的深入分析和防御方法的提出就主要以spectre v1攻击为例。

本文假设攻击者的目标是通过利用图 2所示的代码片段读取任意内存数据,同时防御对象是操作系统内核操作,例如内核通过合法操作使用受害者的私密数据。此外,本文假设攻击者具备如下能力:1) 能成功发起基于缓存的侧信道攻击,即有能力和特权在任何特定时间探测、刷新或驱逐任何cache line,能使用rdtsc和rdtscp等指令进行精确的时间度量;2) 攻击者和受害者共享分支预测部件并且有能力训练该部件;3) 攻击者在用户态模式下以任意参数调用系统调用。最后本文还假设攻击者与内核代码只能通过基于缓存的微架构侧信道进行通信,没有其他可利用的侧信道用于泄露私密数据。

3 设计与实现 3.1 对spectre攻击的建模分析

仍以图 2所示的spectre v1攻击为例,将可能的指令执行流程抽象为图 3所示的阶段模型。假设不允许推测执行,即处理器严格按照程序顺序串行执行相关指令,如图 3a所示,边界检查指令(x < array1_size)通过调度进入执行单元,读取array1_size的值,如果该值不在缓存中,则需要访问更慢速的内存,此时处理器停止指令的继续执行,等待取值结果,经过若干时钟周期后读到结果,再执行比较指令,发现越界访问,最终退出。显然,这种情况并不存在spectre攻击漏洞。

图 3 spectre攻击漏洞指令执行阶段模型

假设允许推测执行,则当边界检查指令进入某一执行单元时,因读取array1_size的值需要等待较长时间(此条件可以通过事先保证array1_size缓存失效得到满足),处理器此时推测执行后续指令(分支预测给出错误预测)。于是,攻击者立即尝试读取私密数据k,即array1[x](此条件可以通过内核操作提前将k读至缓存得到满足,如系统调用)。随后攻击者构造缓存侧信道,试图以k为索引,读取array2,造成缓存访问痕迹。

可以看到,此时会出现竞争情况:1) 如图 3b所示,若在读取array1[x]之前,CPU捕获到数组越界异常,则处理器将清空重排缓冲区后续的微操作,清空指令译码队列,立即停止推测执行。换言之,array2读取操作永远得不到执行,缓存侧信道构造失败,spectre攻击失败。2) 如图 3c所示,若读取array1[x]赶在CPU捕获到数组越界异常之前,则攻击者成功构造缓存侧信道,根据文[15]的结论,此时一定能将私密数据传输出去。

通过上述对spectre攻击的建模分析可知,推测执行的漏洞之所以能被攻击者利用,关键在于满足了相关的竞争条件。反过来讲,研究者可以通过使竞争条件得不到满足,达到防御spectre攻击的目的。

3.2 exLCL的设计与实现

仍以spectre v1攻击为例,根据节3.1的分析,竞争点出现在CPU捕获数组越界异常上,要使得竞争条件得不到满足,关键是要尽可能推迟读取array1[x],使其晚于异常捕获。由于array1[x]对应的k是在缓存中的,如果增大缓存的访问时延,特别是L1缓存的访问时延,则将达到推迟读取array1[x]的目的。本文主要遵循上述思路,提出一种防御spectre攻击漏洞的方法——exLCL(extend L1 cache latency)。

3.2.1 设计实现exLCL

攻击者通常预先将array1[x]所代表的私密数据k读取到缓存中,以求在推测执行时快速访问该数据。在缓存结构中,访问L1数据缓存速度最快,因此假设攻击者在L1数据缓存中访问k时命中是合理的。本文的防御方案exLCL思路简单:要想推迟读取k,可以增大其L1数据缓存的访问时延,对系统性能与安全属性进行折中处理。

具体而言,exLCL的实现包含两步:1) 为使性能开销达到最小,对潜在的攻击代码进行分析,标记相关指令,这也是现有防御方案的共同基础;2) 对于标记指令译码后的加载操作,逐渐增大L1数据缓存的访问时延,直至攻击不成功,由此得到竞争失败所对应的阈值。

指令标记  指令标记的任务是识别所有可用于泄露信息的瞬态加载。严格地说,任何在到达重排缓冲区头部之前初始化读操作的加载都是瞬态加载。exLCL感兴趣的是瞬态加载的子集,它们可能由于推测执行而造成安全漏洞,即不安全的瞬态加载。在spectre攻击模型中,不安全的瞬态加载是在未解析完成的控制流结构之后的瞬态加载。控制流指令一旦被解析,不安全的瞬态加载就会沿着分支的正确路径转换为安全加载。exLCL修改了gem5模拟器的O3CPU乱序CPU模型,以标记所有不安全的瞬态加载。具体来说,在IEW(发射/执行/回写)单元中将未解析的控制流指令之后的所有加载指令标记为不安全的瞬态加载,并在控制流指令提交时删除标记。

增大L1缓存访问时延  对于已标记的瞬态加载操作,exLCL在gem5模拟器中修改配置,增大对应的L1缓存的访问时延。例如,假设L1缓存的访问时延为变量x,瞬态加载操作映射为函数f(x)。exLCL观察并记录f(x)随着x的变化情况,即此时的瞬态加载操作是否满足前述阶段模型的竞争条件。若攻击者竞争成功,则继续增大x,直至竞争失败。竞争失败时对应的x被称为竞争阈值。

3.2.2 exLCL讨论

本文主要以spectre v1攻击为例介绍exLCL的防御原理,然而这并不意味着exLCL只适用于防御spectre v1。因为exLCL的设计中首先识别的是不安全的瞬态加载操作,而不安全的瞬态加载操作存在于许多spectre攻击变种中。此外,exLCL增大L1缓存的访问时延,推迟了不安全的瞬态加载的完成时间,最终使得攻击者在竞争条件下失败,导致攻击无效。为验证exLCL的有效性,本文在gem5模拟器实现了多个spectre攻击变种,具体评估结果详见节4.2.1。

4 评估 4.1 实验配置

为评估exLCL的安全性及性能,采用gem5[23]模拟器进行实验。gem5模拟器提供了x86指令集微操作译码,并且提供了spectre攻击测试框架和可视化工具,支持对exLCL的安全性的验证。gem5具体的配置参数如表 1所示。

表 1 gem5配置参数表
架构 2-core out-of-order, no SMT, 1 GHz
CPU核心 ROB-192 Entry, LQ/SQ-32 Entry Tournament Branch-Pred, BTB-4 096 entry, RAS-16 entry
L1指令缓存 32 kB, 8-Way, 64 B line, 2-cycle RT Latency
L1数据缓存 32 kB, 8-Way, 64 B line, 2-cycle RT Latency
L2缓存(inclusive) 256 kB, 16-Way, 64 B line, 12-cycle RT Latency
共享L3缓存(inclusive) 2 MB, 16-Way, 64 B line, 40-cycle RT Latency

为评估exLCL的安全性,即验证exLCL是否真能防御spectre攻击,本文在gem5中实现了如下spectre攻击变种代码:spectre-PHT (v1,v1.1)[1, 21]、spectre-BTB (v2)[1]和spectre-RSB (ret2spec)[4]

本文从SPLASH-2[24]中选取3个、从SPEC CPU2006[25]中选取7个,总共10个基准测试程序进行测试。对于SPEC CPU2006,按惯例使用参考输入规模,先跳过前100亿条指令,再模拟执行10亿条指令。

4.2 实验结果 4.2.1 exLCL安全性评估

以spectre v1为例介绍安全性评估方法:对于spectre v1,若攻击者攻击成功,即构造了缓存侧信道,则私密数据k对应的array2的数组元素的访问时延将明显降低,例如仅需5~7个时钟访问时延(因为攻击者成功将其缓存),而其他数组元素需要150~200个时钟访问时延。如果使用了exLCL防御方案并且防御成功,扫描array2的数组元素将无法得到有访问时延明显降低的数组元素,即此时所有的数组元素均需要150~200个时钟访问时延,这意味着攻击者无法构造缓存侧信道泄露私密数据。

针对不同spectre变种的安全性评估结果显示,exLCL可以防御spectre v1、v1.1、spectre-BTB及spectre-RSB攻击。例如,对于spectre v1、v1.1,由于二者都是绕过边界检查推测执行错误的指令流,并且都利用基于缓存的侧信道攻击技术,因此增大L1数据缓存的访问时延,使竞争条件得不到满足,就可防御该漏洞。在gem5上的多次独立重复实验结果表明:平均L1数据缓存调整到约13个时钟访问时延(略大于L2缓存的12个时钟访问时延),攻击者就无法利用缓存侧信道技术传输私密数据。

4.2.2 exLCL性能评估

在性能评估中,以归一化运行时间为指标比较不同基准测试程序下exLCL的性能。归一化运行时间的定义为启用exLCL防御机制与不启用情况下,运行各基准测试程序所需时间的比值。理论上,启用exLCL改变了原有访问时延,因此会带来运行时间增加等性能开销,但也意味着程序不存在spectre攻击风险,安全性可得到保证。

图 4a图 4b分别展示了SPLASH-2和SPEC CPU2006的归一化运行时间。对于SPLASH-2的3个基准程序,exLCL的平均性能开销是69%;对于SPEC CPU2006的7个基准程序,exLCL的平均性能开销是73%。实验结果符合预期,exLCL防御方法是可行的。

图 4 SPLASH-2和SPEC CPU2006测试程序归一化运行时间

4.2.3 与现有防御方案的对比

现有防御方案中,有一类方案的思路是禁止部分有可能在推测执行阶段带来安全危害的指令乱序执行,例如插入序列化指令LFENCE[26]。本文将exLCL与LFENCE进行对比,主要比较性能开销。在gem5中实现了LFENCE方案,并基于同样的基准测试程序计算平均性能开销。表 2展示了对比结果。可以发现,在性能开销上,exLCL略好于LFENCE。但是,LFENCE需要添加额外的序列化指令,而exLCL则不需要,并且exLCL处理逻辑更简单。

表 2 exLCL与LFENCE平均性能开销的对比结果
基准测试程序 exLCL/% LFENCE/%
SPLASH-2 69 70
SPEC CPU2006 73 76

4.2.4 未来工作

目前,学术界又提出了许多针对spectre攻击的防御方案,例如基于安全过滤器的Conditional Speculation[27]防御方案,其思路也是禁止部分有可能在推测执行阶段带来安全危害的指令的乱序执行。此外,还有另一类防御思路是设计一套完整的专供处理器在推测执行阶段使用的微体系架构。处理器在预测执行阶段使用的数据只能加载到该专用架构中而不能修改通用微体系架构的状态,以此避免基于缓存的侧信道攻击,如Invisispec[28]和SafeSpec[29]。本文作者的未来工作是将exLCL与上述防御方案进行详细对比。

5 结论

以spectre攻击为代表的推测执行漏洞,对计算机安全提出了严峻挑战。本文以spectre v1攻击漏洞为例,针对漏洞的指令执行流程,建立阶段模型,深入分析利用漏洞需满足的竞争条件。基于该结论,本文提出了一种防御spectre攻击的方案——exLCL。exLCL通过增大L1数据缓存的访问时延,破坏利用漏洞所需满足的竞争条件,从而达到防御目的。基于gem5的模拟实验结果证明exLCL是有效和可行的。与LFENCE对比,exLCL胜在无须添加额外的序列化指令,处理逻辑更简单。

参考文献
[1]
KOCHER P, HORN J, FOGH A, et al. Spectre attacks: Exploiting speculative execution[C]//Proceedings of 2019 IEEE Symposium on Security and Privacy (SP). San Francisco, USA, 2019: 1-19.
[2]
LIPP M, SCHWARZ M, GRUSS D, et al. Meltdown: Reading kernel memory from user space[C]//Proceedings of the 27th USENIX Security Symposium. Baltimore, USA, 2018: 973-990.
[3]
HORN J. Speculative execution, variant 4: Speculative store bypass[EB/OL]. (2018-05-22)[2020- 08-18]. https://bugs.chromium.org/p/project-zero/issues/detail.
[4]
KORUYEH E M, KHASAWNEH K N, SONG C Y, et al. Spectre returns! Speculation attacks using the return stack buffer[C]//Proceedings of the 12th USENIX Conference on Offensive Technologies. Baltimore, USA, 2018.
[5]
SCHWARZ M, SCHWARZL M, LIPP M, et al. NetSpectre: Read arbitrary memory over network[C]//Proceedings of the 24th European Symposium on Research in Computer Security. Cham, Switzerland: Springer, 2019: 279-299.
[6]
CHEN G X, CHEN S C, XIAO Y, et al. SgxPectre: Stealing Intel secrets from SGX enclaves via speculative execution[C]//Proceedings of 2019 IEEE European Symposium on Security and Privacy (EuroS & P). Stockholm, Sweden, 2019: 142-157.
[7]
WEISSE O, VAN BULCK J, MINKIN M, et al. Foreshadow-NG: Breaking the virtual memory abstraction with transient out-of-order execution[R/OL]. (2018-08-14)[2020-08-18]. https://foreshadowattack.eu/foreshadow-NG.pdf.
[8]
YU J Y, YAN M J, KHYZHA A, et al. Speculative taint tracking (STT): A comprehensive protection for speculatively accessed data[C]//Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture. Columbus, USA, 2019: 954-968.
[9]
Intel. Speculative execution side channel mitigations[R/OL]. (2018-05-23)[2020-08-18]. https://software.intel.com/…/speculative-execution-side-channel-mitigations.html.
[10]
AMD: Software techniques for managing speculation on AMD processors[R/OL]. (2018-01-26)[2020-08-18]. https://firmwaresecurity.com/2018/01/26/amd-software-techniques-for-managing-speculation-on-amd-processors/.
[11]
AINSWORTH S, JONES T M. MuonTrap: Preventing cross-domain spectre-like attacks by capturing speculative state[C]//Proceedings of ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). Valencia, Spain, 2020: 132-144.
[12]
TARAM M, VENKAT A, TULLSEN D. Context-sensitive fencing: Securing speculative execution via microcode customization[C]//Proceedings of the 24th International Conference on Architectural Support for Programming Languages and Operating Systems. Providence, USA, 2019: 395-410.
[13]
KORUYEH E M, SHIRAZI S H A, KHASAWNEH K N, et al. SPECCFI: Mitigating spectre attacks using CFI informed speculation[C]//Proceedings of 2020 IEEE Symposium on Security and Privacy (SP). San Francisco, USA, 2020: 39-53.
[14]
KIRIANSKY V, LEBEDEV I, AMARASINGHE S, et al. DAWG: A defense against cache timing attacks in speculative execution processors[C]//Proceedings of the 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). Fukuoka, Japan, 2018: 974-987.
[15]
XIAO Y, ZHANG Y Q, TEODORESCU R. SPEECHMINER: A framework for investigating and measuring speculative execution vulnerabilities[C]//Proceedings of the Network and Distributed Systems Security (NDSS) Symposium. San Diego, USA, 2020.
[16]
CANELLA C, KHASAWNEH K N, GRUSS D. The evolution of transient-execution attacks[C]//Proceedings of 2020 on Great Lakes Symposium on VLSI. Virtual Event, Beijing, China, 2020: 163-168.
[17]
KOCHER P C. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems[C]//Proceedings of the 16th Annual International Cryptology Conference. Berlin, Germany: Springer, 1996: 104-113.
[18]
OSVIK D A, SHAMIR A, TROMER E. Cache attacks and countermeasures: The case of AES[C]//Proceedings of the Topics in Cryptology: CT-RSA 2006. Berlin, Germany: Springer, 2006: 1-20.
[19]
PERCIVAL C. Cache missing for fun and profit[C]//Proceedings of BSDCan 2005. Ottawa, Canada, 2005.
[20]
YAROM Y, FALKNER K. FLUSH+RELOAD: A high resolution, low noise, L3 cache side-channel attack[C]//Proceedings of the 23rd USENIX Conference on Security Symposium. San Diego, USA, 2014: 719-732.
[21]
KIRIANSKY V, WALDSPURGER C. Speculative buffer overflows: Attacks and defenses[Z/OL]. arXiv preprint arXiv: 1807.03757, 2018.
[22]
CANELLA C, VAN BULCK J, SCHWARZ M, et al. A systematic evaluation of transient execution attacks and defenses[C]//Proceedings of the 28th USENIX Conference on Security Symposium. Santa Clara, USA, 2019: 249-266.
[23]
BINKERT N, BECKMANN B, BLACK G, et al. The gem5 simulator[J]. ACM SIGARCH Computer Architecture News, 2011, 39(2): 1-7.
[24]
WOO S C, OHARA M, TORRIE E, et al. The SPLASH-2 programs: Characterization and methodological considerations[J]. ACM SIGARCH Computer Architecture News, 1995, 23(2): 24-36.
[25]
HENNING J L. SPEC CPU 2006 benchmark descriptions[J]. ACM SIGARCH Computer Architecture News, 2006, 34(4): 1-17.
[26]
Intel. Intel analysis of speculative execution side channels[R/OL]. (2010-01-00)[2020-08-18]. https://www.intel.com/content/www/us/en/architecture-and-technology/intel-analysis-of-speculative-execution-side-channels-paper.html.
[27]
LI P N, ZHAO L T, HOU R, et al. Conditional speculation: An effective approach to safeguard out-of-order execution against spectre attacks[C]//Proceedings of 2019 IEEE International Symposium on High Performance Computer Architecture (HPCA). Washington DC, USA, 2019: 264-276.
[28]
YAN M J, CHOI J, SKARLATOS D, et al. InvisiSpec: Making speculative execution invisible in the cache hierarchy[C]//Proceedings of the 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). Fukuoka, Japan, 2018: 428-441.
[29]
KHASAWNEH K N, KORUYEH E M, SONG C Y, et al. SafeSpec: Banishing the spectre of a meltdown with leakage-free speculation[C]//Proceedings of the 56th ACM/IEEE Design Automation Conference (DAC). Las Vegas, USA, 2019: 1-6.