summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIru Cai <mytbk920423@gmail.com>2019-05-10 07:30:58 +0800
committerIru Cai <mytbk920423@gmail.com>2019-05-10 07:30:58 +0800
commite452464c954bca0098aa714ffd03c02ae4c42566 (patch)
treee7cb5ee67d5c1c54b222a5ff8801d0cf3d432d9b
parentb445a8d66a0bd5cd31f3d2f80a23065ed7bea6aa (diff)
downloaddissertation-e452464c954bca0098aa714ffd03c02ae4c42566.tar.xz
import gtran for conditional speculation
-rw-r--r--chap/chap3.tex118
1 files changed, 101 insertions, 17 deletions
diff --git a/chap/chap3.tex b/chap/chap3.tex
index c9297e2..5fdd73e 100644
--- a/chap/chap3.tex
+++ b/chap/chap3.tex
@@ -123,30 +123,114 @@ CSF 防御 Spectre 的开销在 8\% 以下。
\subsubsection{Conditional Speculation}
-Conditional Speculation\supercite{conditional-speculation} 是一种检测
-推测式执行中的潜在的泄露数据的访存指令,并阻止其执行的方法。为了检测可
-能泄露数据的访存指令,此工作提出安全相关(security dependence)的概念,
-对于信道 $c$,指令 $j$ 安全依赖于指令 $i$,如果:
+条件推测式执行(Conditional Speculation)
+\supercite{conditional-speculation} 是一种检测推测式执行中的潜在的泄露
+数据的访存指令,并阻止其执行的方法。为了检测可能在推测式执行中泄露数据
+的指令,此工作提出安全依赖(security dependence)的概念,类似于数据依
+赖和控制依赖,这种新的依赖性用于描述泄漏微架构信息具有潜在安全风险的推
+测性执行的指令。对于信道 $c$,指令 $j$ 安全依赖于指令 $i$,如果:
\begin{itemize}
\item 在程序序列中,指令 $j$ 在 $i$ 之前
\item $j$ 在 $i$ 之前推测式地执行,并且 $j$ 会通过信道 $c$ 泄露数据
\end{itemize}
-存在安全相关的指令可能泄露数据,处理器对其做出标记。为了减少阻止存在安
-全相关的指令执行造成的性能损失,可以使用两个过滤器进一步检测指令是否可
-以安全执行:
+因为信息可以从多种信道上泄露,所以安全依赖的定义指定了某种信道。针对缓
+存信道,如果指令 $j$ 不修改缓存的内容,则它对于缓存信道不具有安全依赖,
+尽管它可能会泄露某些信息。
-\begin{itemize}
-\item 基于缓存命中的过滤器:如果访存指令在缓存中命中,这样的指令不会修
- 改缓存的内容,从而不会泄露数据,这样的指令可以执行。
-\item 基于可以页的过滤器:考虑 Flush+Reload 等常见的基于共享内存的高速
- 缓存侧信道攻击,在一个 Spectre 组件中,存在两个内存访问操作,一个访
- 问秘密数据,一个泄露秘密数据,泄露数据的访存操作访问了攻击者和受害者
- 共享的内存区域,和秘密数据位于不同的物理页。根据这个性质,在遇到一个
- 被标记的访存指令时,可以检测它是否和访存队列中已有的指令是否访问相同
- 的物理页,判断指令是否安全。
-\end{itemize}
+根据以上定义,表\ref{tab:secdep}总结了 Spectre 攻击中的主要的安全依赖。
+Spectre 攻击的安全依赖性来自两种情况,访存-访存推测和分支-访存推测。
+
+\begin{tabular}{|c|c|c|}
+\hline
+Spectre 变体 & 指令 $i$ & 指令 $j$\tabularnewline
+\hline
+\hline
+Spectre v1 & 条件分支 & 访存\tabularnewline
+\hline
+Spectre v2 & 间接转移 & 访存\tabularnewline
+\hline
+Spectre v4 & 访存 & 访存\tabularnewline
+\hline
+SpectrePrime & 条件分支 & 访存\tabularnewline
+\hline
+\end{tabular}
+
+在条件推测式执行的流水线中,在发射队列中引入了安全冒险检测,以识别具有
+安全依赖的可疑的不安全指令。只要在执行阶段确认了真正的冒险,那些不安全
+的推测式执行将会使用现有的重执行和推测式执行恢复机制终止并丢弃。
+
+% the following is from gtran
+
+我们设计了基于比特矩阵的安全检测逻辑,如图2所示。比特矩阵是一些商品处理器用来跟踪数据依赖和年龄信息的流行方式[26],[27],[28]。通常,数据依赖矩阵和年龄矩阵一起可以确定要发布的指令。对于安全检测模块,安全依赖矩阵还必须确定要发布的指令是否具有任何安全依赖性。
+
+矩阵组织:安全依赖矩阵需要有效地支持行和列访问。假设问题队列具有N个项,则安全依赖性矩阵将包含NxN位的寄存器阵列。它由IQPos(问题队列位置)编制索引。此矩阵的读端口数等于调度宽度,写端口数等于发布宽度。给定任何指令X,IQPos X表示其在问题队列中的位置。如果Matrix [IQPos X,IQPos Y]的值为1,则X对Y具有安全依赖性。否则,这意味着它们之间没有安全依赖性。矩阵初始化:当新指令X被分派到问题队列中时,一个条目被分配索引IQPos X.对于此时在问题队列中有效的每个指令Y,计算Matrix [IQPos X,IQPos Y]根据以下公式。
+
+Matrix[X, Y ] = (IssueQ[X].opcode == MEMORY)
+and (IssueQ[Y ].opcode == MEMORY or BRANCH)
+and IssueQ[Y ].valid
+and \!IssueQ[Y].issued
+
+此公式基于以下逻辑来确定指令之间的安全依赖性。首先,如果在X被分派到问题队列之前Y是有效的,则意味着Y在X之前。其次,对于Specter变体,我们仅检查存储器指令是否依赖于先前的分支或存储器指令。第三,如果在发出存储器指令时,先前的分支或存储器指令仍然在问题队列中等待,则该存储器指令将被认为具有安全依赖性。
+
+危险检测:图2说明了问题队列的三个阶段选项。在第一阶段,数据依赖矩阵生成依赖向量。在第二阶段,然后将该向量发送到年龄矩阵以选择要发布的最早的就绪指令。在第3阶段,对于选择发布的那些指令,查询安全依赖矩阵以获得它们的安全依赖性,然后更新问题队列的相应条目的状态。特别是,安全依赖矩阵的每一行中的位由OR运算处理,结果表明是否存在潜在的安全隐患。当选择发出一条指令并检测到安全危险时,它将被标记为可疑推测标记。
+
+依赖性清除:在发出一条指令X后,更新向量寄存器中的相应位将被设置为0.由IQPos X索引的安全依赖矩阵列将在下一个周期复位。这种操作意味着清除了相应指令和X之间的安全依赖性。
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+为了性能,安全性和透明性的平衡,条件推测式执行提出了两种过滤机制,以找
+出错误识别的安全安全冒险。基于缓存命中的冒险过滤器针对命中缓存的推测式
+执行指令。因为它们的推测式执行不会改变缓存的内容,所以它们是安全的。
+另一个提出的过滤器,基于可信页面缓冲区(Trusted Page Buffer, TPBuf)的
+冒险过滤器,从另一个角度识别安全的推测推测式执行的指令。对于使用基于共
+享内存(例如 Flush+Reload)的缓存侧通道攻击窃取内存信息的 Spectre 变体,
+他们对恶意组件的推测式执行具有名为 S-Pattern 的共同特征。 TPBuf 从所有
+推测式执行中捕获 S-Pattern,对于任何推测式执行的访存指令,如果它与
+S-Pattern 不匹配,则被认为是安全的。
+
+% gtran
+
+一种简单的危险消除方法是简单地阻止在发布队列中标记有可疑推测标记的所有指令。这样的政策显然会导致性能下降。同时,只有导致高速缓存未命中的内存请求将改变高速缓存内容,并且大多数应用程序表现出良好的时间和空间局部性。受这两个观察的启发,基于缓存命中的危险过滤器被提议用于减少保守地不执行具有可疑推测标记的指令的性能影响。
+
+% hit-based
+
+对于标记有可疑推测标志的存储器指令,它将被推测性地发布到存储器访问管线。如果推测性存储器访问命中L1高速缓存,则其执行将继续作为正常存储器指令。但是,如果遇到L1高速缓存中的未命中,则丢弃的请求将被丢弃。信号从L1高速缓存发送回问题队列,重新发出逻辑应该应用于存储器指令,直到其安全依赖性得到解决。这些被阻止的指令在发布队列中等待安全依赖性在重新发布之前清除。此设计仅需要L1高速缓存控制逻辑中的最小更改:将不会处理具有可疑推测标记的未命中请求。
+
+% TPBuf
+基于缓存命中的危险过滤器仅考虑在L1 DCache中命中的推测性内存指令是安全的,并允许它们被推测性地执行。对于具有高L1 DCache未命中率的应用程序,它将无法恢复投机执行的大部分好处。对于这些应用,我们提出了一种新的危险过滤器可信页面缓冲器(TPBuf)来检测L1 DCache中丢失的指令的安全推测。 TPBuf基于以下观察:并非所有推测性缓存未命中都可用于构建推测性侧通道。基于第3节中定义的威胁模型,我们关注使用共享内存(例如,Flush + Reload)范例和非法访问内存页面信息的Spectre变体。如图3所示,恶意小工具的推测性执行在我们的目标Spectre攻击中被用作通用内存访问模式。特别是,观察到恶意推测执行流程总是包含两个特殊的存储器指令(A和B)。这两条指令具有以下用法和行为。
+
+1)A用于推测性地访问敏感数据。 B推测访问攻击者共享的内存区域,用于构建受害者和攻击者之间的缓存侧通道。由于用于侧信道的秘密数据和存储区域通常位于不同的存储页面,因此这两条指令访问不同的页面。
+
+2)为了构建缓存侧通道,攻击者需要首先刷新特定的共享内存数据。然后,B的诱导推测执行具有高速缓存未命中,因此将高速缓存行重新加载到L1 DCache中。攻击者可以通过缓存侧信道感知状态信息的这种变化。因此,B的高速缓存未命中对于通过高速缓存侧信道泄漏敏感信息是必要的。
+
+3)B是数据依赖于A.A的结果用于计算共享存储区域的索引。这种精心设计的依赖性也是攻击者推断秘密价值的另一个重要点。
+
+在上述观察的推动下,我们将上述共同特征行为称为S模式。具体地,如果观察到推测执行的指令序列具有以下特征,则我们认为该推测指令序列具有S模式行为。
+
+1)至少有两个指令(A和B)分别访问不同的存储页面。
+
+2)指令B导致L1 DCache未命中。
+
+3)指令B具有数据依赖于指令A.
+
+4)A和B之间可能有多个指令(计算,存储器或其他类型的指令)。
+
+ 尽管Spectre攻击的恶意小工具被称为S-Pattern行为,但应该注意的是,具有S-Pattern的指令流不一定是幽灵攻击。出于安全原因,我们试图在微体系结构层面上防止形成具有S-Pattern的推测性指令流。在确保安全性的同时,这种机制自然也会导致性能损失。在第6节中,我们详细评估了该策略的性能,并分析了正常程序(如SPEC CPU 2006)中S-Pattern的比例。
+
+ TPBuf旨在通过所有推测执行的S-Pattern捕获内存访问行为。 它记录所有动态推测存储器访问请求并跟踪它们的执行状态(例如,是否重新填充所请求的高速缓存行)。 当一个错过L1 DCache的新内存请求时,TPBuf会将其页面地址与其历史记录进行比较。 并且它根据表II中描述的逻辑决定这种新的推测指令是否安全。
+
+ TPBuf的微体系结构如图4所示。一个主要的设计原则是尽可能利用现有逻辑来降低实现的复杂性,例如避免TPBuf成为核心管道内的新时序关键路径。 TPBuf靠近加载存储队列(LSQ),其条目与LSQ的条目具有1:1映射。 TPBuf条目的分配,提交和压缩与LSQ的Head和Tail指针的移动一起操作。此外,TPBuf涵盖了推测执行窗口中的所有动态推测存储器指令。为了防止攻击者直接推测性地访问未授权数据然后将数据传播到他自己的存储空间,必须首先检查访问地址并使用TLB获取物理页码(PPN)。 TPBuf记录并使用PPN作为每个条目的标记。此外,每个TPBuf条目都存储一个掩码和许多状态位。 TPBuf检测S模式并将结果传递给Cache-hit过滤器,该过滤器决定是否应该阻止可疑的推测性未命中请求。这样,原始内存一致性模型和缓存一致性不受影响。 TPBuf的查找如图4所示。
+
+分配:当在LSQ中分配存储器访问指令时,它们也在TPBuf中分配并且A位被置位。并且根据TPBuf中的A位生成掩码。
+它指示TPBuf中的哪些内存指令比程序顺序中的新条目旧。
+
+更新:使用存储器指令附带的可疑推测标志更新S位。当PPN记录在TPBuf中时,V位置位。当存储器指令获取的数据可供其他指令使用时,W置位。
+
+检测:当传入请求进入TPbuf时,TPBuf将其PPN与现有条目的PPN进行比较,然后生成地址匹配向量(匹配)。这些矢量,包括Match,V,W和S,用作等式1逻辑的输入,以确定请求是否安全。特别地,“|”表示减少OR,它对向量中的所有位进行OR运算以生成1位输出。
+%%%%%%%
在 gem5 模拟器中用 SPEC CPU2006 进行评测,平均性能开销为 6.8\%.