CN108427576A - 一种免受Spectre攻击的高性能推测执行算法 - Google Patents

Abstract

本发明公开了CPU安全技术领域的一种免受Spectre攻击的高性能推测执行算法，该免受Spectre攻击的高性能推测执行算法的具体步骤如下：S1：译码、派遣阶段；S2：重命名阶段；S3：访存请求发送阶段；S4：下级缓存请求发送阶段，本方案综合考虑了修复硬件成本和安全性，保证推测执行在安全的检测隔离环境中发挥原有的性能优势，相比原有推测执行算法，本发明重点解决了Spectre多种攻击变体的攻击免疫问题，从根本上保障了推测执行不会引发用户信息泄露，相比原来，本方案会消耗额外硬件增加检测隔离机制，对威胁性的访存序列，采取安全保守的执行机制，从而可能在少数场景有性能损失。

Description

一种免受Spectre攻击的高性能推测执行算法

技术领域

本发明涉及CPU安全技术领域，具体为一种免受Spectre攻击的高性能推测执行算法。

背景技术

近期暴露的CPU底层硬件设计缺陷包括Meltdown和Spectre，破坏用户级别和特权级别隔离机制，并提供不同用户进程之间的非法访问通道以及云端信息窃取途径。Spectre缺陷利用推测执行的副作用，诱使CPU执行不该执行的程序路径，从而在数据缓存中留下操作痕迹，最后利用侧信道攻击恢复机密数据。各大主流操作系统厂商和通用软件提供商，发布了修复性的patch，并完成了自底向上适配，以显著性的性能牺牲换取用户信息安全。现有技术的缺陷和不足：

基于Spectre缺陷的攻击由于利用了绝大多数现代处理器都会使用的推测执行技术，因此影响到所有主流处理器，现有硬件设计无法通过简单的配置或是控制避免推测执行，而关闭推测执行会使CPU性能下滑严重，因此只能依靠操作系统的修复来避免被攻击，但是依然会在特定应用领域或场景下带来可观的性能损失。此外软件修复可能无法适应灵活多变的攻击变体，不能从根本上完全杜绝此类问题。

发明内容

本发明的目的在于提供一种免受Spectre攻击的高性能推测执行算法，以解决上述背景技术中提出的现有硬件设计无法通过简单的配置或是控制避免推测执行，而关闭推测执行会使CPU性能下滑严重，因此只能依靠操作系统的修复来避免被攻击，但是依然会在特定应用领域或场景下带来可观的性能损失。此外软件修复可能无法适应灵活多变的攻击变体，不能从根本上完全杜绝此类问题。

为实现上述目的，本发明提供如下技术方案：一种免受Spectre攻击的高性能推测执行算法，该免受Spectre攻击的高性能推测执行算法的具体步骤如下：

S1：译码、派遣阶段：

通过分支预测之后的分支指令会被标记是否被预测执行，这个状态会被传递到派遣单元，Recorder结构会记录下来最近被预测执行的一笔分支指令，并把自身状态设置为busy，如果这笔最近被预测的分支指令被提交，那么recorder会切换到idle的状态，表明没有预测的分支指令在乱序执行过程中。通过这一结构，所有到达派遣单元的指令都会知道自己是否处在推测执行的状态下，从而为进一步的攻击特征提取提供最初的选定范围。

S2：重命名阶段：

传统意义的重命名阶段，负责解决数据冲突问题，为指令建立关联性，其内部主体包含一个寄存器别名表，记录逻辑寄存器与物理寄存器的映射关系。Spectre的攻击程序特征是在推测执行的路径上存在一个间址寻址的指令。

从派遣阶段出来以后，所有加载指令都会被标识是否处于推测执行的状态中，以及到底依赖于最近的哪一笔分支指令，这两个信息会在目标寄存器更新寄存器别名表的同时，顺便被记录在别名表里，此外如果当前指令的源寄存器在访问寄存器别名表时，发现依赖于早前的一笔推测执行的加载指令时，会把这个推测状态同样记录在自己目的寄存器在寄存器别名表对应的表项里，这样就完成了推测执行状态和依赖分支指令的传递过程，我们称之为“着色”。

S3：访存请求发送阶段：

从重命名阶段出来以后每条加载指令会携带是否为推测执行的间址访存指令的指示位以及依赖的分支指令，这时候考虑到设计的复杂程度和访存的保守程度，分为几种不同做法：

(1)只要当前加载指令为推测执行的间址访存指令，把他设置为in-order执行，即当提交指针等于当前指令ID的时候才可以被发射，这就保证了之前没有任何speculation的成分。

(2)只要当前加载指令为推测执行的间址访存指令，把他依赖的分支指令以ID的形式存在发射Queue中，monitor提交指针，当提交指针等于当前保存的分支指令ID的时候才可以被发射，这就保证了之前依赖的分支指令已经被执行而且预测结果也被得到认证。如果分支预测错误，发生flush，清空当前的加载指令，否则可以被发射出去。

(3)只要当前加载指令为推测执行的间址访存指令，把他依赖的分支指令ID随着加载指令本身一同被发射到数据缓存中，如果返回命中，正常返回执行结果和状态，否则进行特殊处理，这就使得访存命中时候的性能不受任何损失。其深层次原理在于，Spectre攻击的最后需要侧信道攻击，侧信道攻击需要把目标地址从cache中先清除，这样才能在重加载的时候通过判断延迟来决定目标地址是否已经在缓存中，因此攻击过程中目标地址的访问一定不会是命中状态，所以只关心带有危险特征访存序列在不命中情况下的隔离问题。

S4：下级缓存请求发送阶段：

发生不命中的推测执行的间址访存的请求会被压到不命中的FIFO结构中，因此可以压制此类对下级缓存的访问请求，与此同时从访存请求发送阶段传送过来的分支指令ID也被存在于FIFO中，用来监测提交指针，当这条所依赖的分支指令被提交时，此条间址请求会采取动作，或是因分支预测错误被清除，或是继续向下级缓存发送请求。

优选的，所述步骤S4中此条间址可采取直接把间址访存请求标成in-order的方式来简化设计。

与现有技术相比，本发明的有益效果是：本方案综合考虑了修复硬件成本和安全性，保证推测执行在安全的检测隔离环境中发挥原有的性能优势，相比原有推测执行算法，本发明重点解决了Spectre多种攻击变体的攻击免疫问题，从根本上保障了推测执行不会引发用户信息泄露，相比原来，本方案会消耗额外硬件增加检测隔离机制，对威胁性的访存序列，采取安全保守的执行机制，从而可能在少数场景有性能损失。

附图说明

图1为本发明重命名阶段的控制流程图；

图2为本发明访存请求发送阶段的控制流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供一种技术方案：一种免受Spectre攻击的高性能推测执行算法，该免受Spectre攻击的高性能推测执行算法的具体步骤如下：

S1：译码、派遣阶段：

通过分支预测之后的分支指令会被标记是否被预测执行，这个状态会被传递到派遣单元，Recorder结构会记录下来最近被预测执行的一笔分支指令，并把自身状态设置为busy，如果这笔最近被预测的分支指令被提交，那么recorder会切换到idle的状态，表明没有预测的分支指令在乱序执行过程中。通过这一结构，所有到达派遣单元的指令都会知道自己是否处在推测执行的状态下，从而为进一步的攻击特征提取提供最初的选定范围。

S2：重命名阶段：

传统意义的重命名阶段，负责解决数据冲突问题，为指令建立关联性，其内部主体包含一个寄存器别名表，记录逻辑寄存器与物理寄存器的映射关系。Spectre的攻击程序特征是在推测执行的路径上存在一个间址寻址的指令，例如

Instr1mov al,[rbx]//the secret locates at[rbx]

Instr2and al,0x1

Instr3mov rax,[al+0x200]//the indirect speculative laod

攻击者首先把0x200和0x300这两个地址从数据缓存中清除，当上面指令序列推测执行结束，攻击者会检测这加载两个地址，根据他们的延迟时间，来间接确认从[rbx]加载出来的机密信息。通过循环多次可以还原完整的地址空间信息。

综上所述，我们要检测的就是推测执行路径上的间址寻址指令。

从派遣阶段出来以后，所有加载指令都会被标识是否处于推测执行的状态中，以及到底依赖于最近的哪一笔分支指令，这两个信息会在目标寄存器更新寄存器别名表的同时，顺便被记录在别名表里，此外如果当前指令的源寄存器在访问寄存器别名表时，发现依赖于早前的一笔推测执行的加载指令时，会把这个推测状态同样记录在自己目的寄存器在寄存器别名表对应的表项里，这样就完成了推测执行状态和依赖分支指令的传递过程，我们称之为“着色”。

S3：访存请求发送阶段：

从重命名阶段出来以后每条加载指令会携带是否为推测执行的间址访存指令的指示位以及依赖的分支指令，这时候考虑到设计的复杂程度和访存的保守程度，分为几种不同做法：

(1)只要当前加载指令为推测执行的间址访存指令，把他设置为in-order执行，即当提交指针等于当前指令ID的时候才可以被发射，这就保证了之前没有任何speculation的成分。这是非常简单的控制和判断，但是会严重影响性能。

(2)只要当前加载指令为推测执行的间址访存指令，把他依赖的分支指令以ID的形式存在发射Queue中，monitor提交指针，当提交指针等于当前保存的分支指令ID的时候才可以被发射，这就保证了之前依赖的分支指令已经被执行而且预测结果也被得到认证。如果分支预测错误，发生flush，清空当前的加载指令，否则可以被发射出去。这种做法比上一种有更好的性能，但是需要牺牲面积来存储依赖的分支指令ID。

(3)只要当前加载指令为推测执行的间址访存指令，把他依赖的分支指令ID随着加载指令本身一同被发射到数据缓存中，如果返回命中，正常返回执行结果和状态，否则进行特殊处理，这就使得访存命中时候的性能不受任何损失。其深层次原理在于，Spectre攻击的最后需要侧信道攻击，侧信道攻击需要把目标地址从cache中先清除，这样才能在重加载的时候通过判断延迟来决定目标地址是否已经在缓存中，因此攻击过程中目标地址的访问一定不会是命中状态，所以只关心带有危险特征访存序列在不命中情况下的隔离问题。

S4：下级缓存请求发送阶段：

发生不命中的推测执行的间址访存的请求会被压到不命中的FIFO结构中，因此可以压制此类对下级缓存的访问请求，与此同时从访存请求发送阶段传送过来的分支指令ID也被存在于FIFO中，用来监测提交指针，当这条所依赖的分支指令被提交时，此条间址请求会采取动作，或是因分支预测错误被清除，或是继续向下级缓存发送请求。当然，依然可以采取直接把间址访存请求标成in-order的方式来简化设计。

以上完成了本次发明涉及到的所有流水线的改动，我们注意到有些场景的执行本身就免于Spectre攻击，为了使这一保护隔离机制的使用更加灵活，我们有专门的体系结构控制寄存器位来选择开启或关闭这一机制。同时我们自主设计的指令集支持快速进行控制寄存器的更新。

实施例

S1：译码、派遣阶段：

需要判断哪些分支指令被预测过，包括两种形式的预测：方向预测，地址预测。方向预测很常见，因为分支指令只存在顺序执行和跳转执行两种不同的执行方向，因此即便分支预测器因设计复杂度而精度各异，总会有默认的执行方向，而地址预测由于分支地址缓存空间有限，可能产生不命中。因此被预测的分支指令的译码逻辑包括：绝对跳转指令且地址被预测，分支跳转指令且地址、方向被同时预测。

接下来需要一个Recorder来记录最新的被预测的分支指令，因为在CPU乱序流水线中，通常用重定序缓存ID作为唯一指令标识，因此Recorder需要记录这一ID。此外一个单独的bit用于标识当前Recorder的状态，如果当前执行有推测执行的成分，那么这个bit会被置位，如果发生流水线cancel或者推测执行被确认(被预测的分支指令全部被提交)，那么这个bit会被清零。所有经过这一阶段的访存加载类指令都需要携带两个信息到后面的流水线：当前是否有speculation成分，最近被预测的分支指令的ID。

S2：重命名阶段：

每个逻辑寄存器的映射关系新增加两个新的域：推测有效位,分支指令ID。如果当前访存类加载指令存在推测执行成分，把目标寄存器对应表项的推测有效位置位，并且把携带的分支ID记录在分支指令ID的位置。此外如果当前指令是普通的拥有目标寄存器的运算类指令，如果源寄存器访问的表项的推测有效位被置位，传递到目标寄存器对应的表项，如果多个源寄存器对应的表项有不同的分支指令ID，选取最新的ID(指令顺序上最新)记录在目标寄存器对应的表项。如果提交阶段返回的分支指令ID和某一表项的index匹配，那么清除出对应的推测有效位，具体控制流程如图1。

S3：访存请求发送阶段：

从重命名阶段传递过来的两个信号分别表示：当前是否是推测执行的间址访存指令，依赖的分支指令ID。当访存请求被发送给缓存，如果命中，不需要做任何处理，完成执行，如果不命中，对于下级缓存的访问请求会被压到FIFO中，此时如果判断为推测执行的间址访存指令，该请求会被block在FIFO中，来防止更改缓存状态，达到切断侧信道攻击源头的目的。

此外如果推测执行的间址访存指令是存储指令，依然需要被block在FIFO中，事实上对于下级缓存，一笔不命中的存储指令和加载指令是一样的行为。

FIFO的每项都会记录分支指令ID，检测分支指令是否被提交，来进行下一步操作：被清除或者向下级缓存取数，具体控制流程如图2。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。

Claims (2)

1.一种免受Spectre攻击的高性能推测执行算法，其特征在于：该免受Spectre攻击的高性能推测执行算法的具体步骤如下：

S1：译码、派遣阶段：

通过分支预测之后的分支指令会被标记是否被预测执行，这个状态会被传递到派遣单元，Recorder结构会记录下来最近被预测执行的一笔分支指令，并把自身状态设置为busy，如果这笔最近被预测的分支指令被提交，那么recorder会切换到idle的状态，表明没有预测的分支指令在乱序执行过程中。通过这一结构，所有到达派遣单元的指令都会知道自己是否处在推测执行的状态下，从而为进一步的攻击特征提取提供最初的选定范围。

S2：重命名阶段：

传统意义的重命名阶段，负责解决数据冲突问题，为指令建立关联性，其内部主体包含一个寄存器别名表，记录逻辑寄存器与物理寄存器的映射关系。Spectre的攻击程序特征是在推测执行的路径上存在一个间址寻址的指令。

从派遣阶段出来以后，所有加载指令都会被标识是否处于推测执行的状态中，以及到底依赖于最近的哪一笔分支指令，这两个信息会在目标寄存器更新寄存器别名表的同时，顺便被记录在别名表里，此外如果当前指令的源寄存器在访问寄存器别名表时，发现依赖于早前的一笔推测执行的加载指令时，会把这个推测状态同样记录在自己目的寄存器在寄存器别名表对应的表项里，这样就完成了推测执行状态和依赖分支指令的传递过程，我们称之为“着色”。

S3：访存请求发送阶段：

从重命名阶段出来以后每条加载指令会携带是否为推测执行的间址访存指令的指示位以及依赖的分支指令，这时候考虑到设计的复杂程度和访存的保守程度，分为几种不同做法：

(1)只要当前加载指令为推测执行的间址访存指令，把他设置为in-order执行，即当提交指针等于当前指令ID的时候才可以被发射，这就保证了这条指令的执行没有推测的成分。

(2)只要当前加载指令为推测执行的间址访存指令，把他依赖的分支指令以ID的形式存在发射Queue中，monitor提交指针，当提交指针等于当前保存的分支指令ID的时候才可以被发射，这就保证了之前依赖的分支指令已经被执行而且预测结果也被得到认证。如果分支预测错误，发生flush，清空当前的加载指令，否则可以被发射出去。

(3)只要当前加载指令为推测执行的间址访存指令，把他依赖的分支指令ID随着加载指令本身一同被发射到数据缓存中，如果返回命中，正常返回执行结果和状态，否则进行特殊处理，这就使得访存命中时候的性能不受任何损失。其深层次原理在于，Spectre攻击的最后需要侧信道攻击，侧信道攻击需要把目标地址从cache中先清除，这样才能在重加载的时候通过判断延迟来决定目标地址是否已经在缓存中，因此攻击过程中目标地址的访问一定不会是命中状态，所以只关心带有危险特征访存序列在不命中情况下的隔离问题。

S4：下级缓存请求发送阶段：

发生不命中的推测执行的间址访存的请求会被压到不命中的FIFO结构中，因此可以压制此类对下级缓存的访问请求，与此同时从访存请求发送阶段传送过来的分支指令ID也被存在于FIFO中，用来监测提交指针，当这条所依赖的分支指令被提交时，此条间址请求会采取动作，或是因分支预测错误被清除，或是继续向下级缓存发送请求。

2.根据权利要求1所述的一种免受Spectre攻击的高性能推测执行算法，其特征在于：所述步骤S4中此条间址可采取直接把间址访存请求标成in-order的方式来简化设计。