1 files changed, 92 insertions, 58 deletions
diff --git a/chap/chap3.tex b/chap/chap3.tex
index aaa7956..045e9a8 100644
--- a/chap/chap3.tex
+++ b/chap/chap3.tex
@@ -66,11 +66,11 @@ retpoline\supercite{retpoline} 是 Google 提出的防御 Spectre-BTB 的方法�
 % TODO:增加 retpoline 的代码？
 
 % index masking
-Webkit 在数组访问中使用 index masking\supercite{webkit} 方法，它让数组
-下标和一个值进行与操作，去掉下标高位的1，将数组下标控制在一定范围内，防
-止处理器在推测式执行中访问数组指定范围之外的数据。Linux 构造了一个粒度
-更细的 array\_index\_nospec\supercite{linux-spec}，它的功能如
-图\ref{fig:array-index-nospec}：
+Webkit 在数组访问中使用索引掩码（index masking）\supercite{webkit} 方
+法，它让数组下标和一个值进行与操作，去掉下标高位的1，将数组下标控制在
+一定范围内，防止处理器在推测式执行中访问数组指定范围之外的数据。Linux
+构造了一个粒度更细的 array\_index\_nospec\supercite{linux-spec}，它的
+功能如图\ref{fig:array-index-nospec}：
 
 \begin{figure}[htbp]
 \begin{minted}[frame=single]{C}
@@ -118,64 +118,53 @@ Google 为 Chrome 浏览器使用了站点隔离（site isolation）技术，使
 
 \Fixme: 需要重新翻译
 
-SafeSpec\supercite{safespec}提出了一种原则性的方法来保护处理器免受推测
-式执行攻击，同时保留执行推测性执行以从其性能中受益的能力。一般原理（如
-图\ref{fig:safespec}所示）使用临时结构（图中的阴影状态）来保存任何以推
-测方式产生的状态，而不会影响处理器的主要结构（我们在图中称为提交状态）。
-例如，如果推测性加载指令导致加载高速缓存行，而不是将该高速缓存行加载到
-处理器高速缓存中，我们将该行保存在临时结构中。如果稍后对加载指令进行压
-缩，则会将这些效果移除（从提交状态开始的底部路径），不会从错误推测的指
-令中更改缓存，并关闭漏洞。或者，如果指令提交，则将高速缓存行从临时结构
-移动到L1高速缓存并从阴影状态中移除。
+SafeSpec\supercite{safespec}提出了一种设计原则保护处理器免受推测式执行
+攻击，同时保持推测式执行带来的性能提升。SafeSpec 的总体设计如图
+\ref{fig:safespec}所示，使用临时结构（图中的影子状态）来保存任何推测式
+执行的指令产生的状态，而不影响处理器的主要结构（在图中称为提交状态）。
+例如，如果推测式执行中的装载指令需要向缓存中填入一个缓存行，则改行保存
+在临时结构中，而不是高速缓存。如果这个指令被取消，则它产生的效果也一起
+被清除，从而错误的推测式执行不会改变缓存状态；如果指令提交，则将这个缓
+存行从临时结构移动至缓存中。
 
 \begin{figure}[htbp]
   \centering
   \includegraphics[width=0.8\textwidth]{safespec.eps}
-  \caption{SafeSpec 总体设计}
+  \caption{SafeSpec 总体设计\supercite{safespec}}
   \label{fig:safespec}
 \end{figure}
 
 虽然SafeSpec原则上很简单，但必须解决许多与其安全性，复杂性和性能相关的
-问题。我们将在本节的其余部分概述这些问题。
-
-% transient to commit
-有两个选项可用于决定何时将状态从阴影移动到已提交状态。在第一个变量中，
-我们称之为等待分支（WFB），我们可以假设一条指令在它所依赖的所有分支
-（更一般地说，所有预测）都已被解析时不再是推测性的。 WFB阻止两种幽灵的
-变种，它们依赖于错误分支预测;没有任何错误推测的指令移动到已提交状态。
-但是，它不会阻止不依赖于分支预测器的Meltdown。第二个变量等待提交（WFC）
-等待直到导致推测性副作用的指令在将其效果移动到提交状态之前提交，因此也
-会阻止崩溃。我们注意到，根据此定义的重新排序缓冲区是一种阴影状态，只有
-在提交指令时，其数据才会移动到永久状态（架构状态）。
-
-阴影状态组织和大小：如果阴影状态结构太小，则替换推测状态（如果稍后将提
-交此数据，则导致丢失对已提交状态的更新），或者指令必须停止，直到那里在
-发布之前，它是投机结构的空间。因此，从性能的角度来看，应该设计影子结构
-的组织和大小，使得结构可以保持通过在典型工作负载上测量的推测产生的推测
-状态。但是，我们将证明安全考虑因素对投机状态提出了更严格的要求。
-
-减轻瞬态猜测攻击：通过构造安全规范可以防止推测值影响已提交结构的状态，
-这是在已发布的推测攻击中隐蔽地传递数据的途径。但是，它不会在处于推测状
-态的指令之间创建隔离。这为我们称为瞬态推测攻击（TSA）的新型攻击创造了
-可能性。特别是，由于提交的指令可以处于推测状态（在它们的依赖分支在WFB
-中提交之前，或者在指令本身在WFC中提交之前），因此有一个时间窗口，它们
-可以在它们之前与错误指定的指令共享推测状态。被压扁了。如果我们不小心，
-可以在此期间创建一个隐蔽通道，将敏感数据从错误推测的分支传递到将要提交
-的分支，从而允许数据被泄露。
-
-考虑一个尺寸小的阴影结构的例子（比如说一个条目）。然后，读取特权数据的
-恶意推测代码可以使用阴影状态秘密地将其传递给推测代码（将提交的“接收器”
-代码）。例如，它可以替换阴影状态中的条目，导致接收者在提交后注意到其推
-测状态（因为它被替换）的缺失。或者，如果我们在阴影结构已满时阻塞，接收
-器可以检测到其代码执行时间较长。
-
-尽管TSA的严重程度远低于原始攻击，但必须仔细考虑它们以确保无法进行泄漏。
-解决此问题的一种方法是对每个分支的推测状态进行分区，或者对其进行大量调
-整，或者甚至在最坏的情况下，以确保通过阴影状态不发生泄漏。 TSA还可以通
-过在功能单元或其他共享结构上创建争用来秘密地进行通信;这是我们也考虑的
-问题。我们将在第五节讨论如何减轻TSA攻击。
-
-过滤延迟的副作用：当指令在执行过程中被压缩时，会发生SafeSpec的一个问题。
+问题。
+
+将状态从影子状态移动到提交状态有两种选择。第一种选择是等待分支（Wait
+  For Branch，WFB），当一个指令依赖的所有分支结果都已经得出时，这个指
+令不再是推测式执行的指令。WFB 可以防御 Spectre v1 和 v2,它们依赖于错误
+的分支预测，没有任何错误的推测式执行产生的状态进入提交状态。而
+Meltdown 不依赖于分支预测，因此 WFB 不能防御 Meltdown. 第二种选择是等
+待提交（Wait For Commit，WFC），在指令提交的时候，才将推测式执行产生的
+状态更新至提交状态。
+
+影子状态的大小是另一个设计选择。如果保存影子状态的结构太小，则会导致推
+测式执行的状态被替换，或指令需要在发射前停顿，直到影子状态有足够的空间。
+因此，影子状态应当设计为能符合一般程序产生的推测式执行状态数量的大小。
+暂态推测式攻击从安全的角度，说明影子状态的大小要足够大。
+
+SafeSpec 防止推测式执行的产生的值影响提交状态，从而阻止了 Spectre 攻击
+通过隐蔽信道传送数据。但是 SafeSpec 并没有隔离推测式执行中的指令的状态，
+这可能造成暂态推测式攻击（Transient Speculation Attack）。由于指令在提
+交前可在推测式执行的状态，在一段时间内，它可以和错误推测式执行的指令共
+享状态。
+
+例如，考虑一个非常小的影子结构（如只有一个条目），恶意的推测式执行的代
+码可以读取一个特权数据，隐蔽地通过影子状态传送这个数据至接收者。它可以
+替换影子状态中的条目，使得接收者发现其推测式执行状态丢失。如果在影子状
+态满时阻塞执行，接收者可以发现它的执行时间变长。
+
+SafeSpec 的一个问题是如果一个长延迟指令，例如从内存中读取数据的指令，
+在执行过程中被取消，它的状态需要丢弃。因此，如果一个长延迟指令的结果返回，
+
+
 如果指令已经启动了高延迟操作，例如从内存中读取，我们必须确保在收到内存
 后可以丢弃内存中的响应。 执行的指令推测性地将任何结果状态存储到阴影结
 构。 因此，如果收到长等待时间回复并且没有匹配的事务，我们只是丢弃这些
@@ -464,9 +453,6 @@ DAWG提供了强大的隔离和合理的性能开销。
 在 zsim 模拟器中使用 SPEC CPU2006, PARSEC, GAPBS 进行模拟，相对于
 Intel CAT，在不同的评测程序和划分方式下，大多数程序性能下降为 4\%\~7\%.
 
-DAWG 的主要缺点是需要操作系统的支持。此外，DAWG 不能防御 NetSpectre 等可
-在同一安全域内进行的攻击。
-
 \subsubsection{Context-Sensitive Fencing}
 
 %\Todo: CSF introduction
@@ -768,3 +754,51 @@ Spectre 攻击需要分为三个步骤：从存储系统装载秘密数据，将
 
 \section{Meltdown 和 Spectre 的防御方案分析}
 
+由于 Meltdown 型攻击和 Spectre 型攻击利用的暂态指令不同，因此防御方案
+也不同。
+
+对于 Meltdown 型攻击，防御方法相对简单。只要使产生异常的指令在微架构层
+次上无法访问体系结构层次上无法访问的数据，即可以阻止 Meltdown 型攻击。
+在现有的处理器中，需要使用 KAISER 等防御方案，会造成一定性能的损失。
+
+Spectre 攻击的防御相对复杂。对于软件防御方案，在分支后添加串行化指令或
+数据依赖，阻止推测式执行的发生，会有 30\% 以上的性能下降。
+\supercite{spec-load-hardening} 使用静态分析工具
+\supercite{oo7}\supercite{spectector}寻找程序中受影响的分支，可以检测
+出受 Spectre 攻击影响的分支，并只对这些分支进行防御，但是这些工具仍然
+未能投入使用。而且，这些方法都只能防御 Spectre v1. Retpoline 有 5\% 至
+10\% 的性能开销\supercite{systematic}，只能用于防御 Spectre v2. 索引掩
+码只用于数组边界检查一类分支，站点隔离只用于浏览器等特定场景。
+
+总的来说，软件防御方案防御的攻击类型有限，而且需要对软件进行修改，而硬
+件防御方案通常不要求软件修改，可以防御多种变体的攻击，这是硬件防御方案
+相对于软件防御方案的优点。
+
+现有的硬件防御方案主要关注高速缓存侧信道。在现有的大部分 Spectre 类型
+攻击中，都使用高速缓存侧信道，因此针对高速缓存侧信道的防御方法可以抵抗
+大多数的攻击。随着侧信道攻击研究的发展，未来的处理器可能需要考虑更多的
+信道。
+
+SafeSpec 的方法是使用临时结构。InvisiSpec 为了处理内存一致性的问题，在
+添加一个推测式执行缓冲区之外，还要增加一个验证步骤，使得 InvisiSpec 具
+有较大的性能开销。
+
+基于缓存隔离的 DAWG 的主要缺点是需要操作系统的支持。此外，DAWG 不能防
+御 NetSpectre 等来源于同一安全域的攻击。
+
+Context-Sensitive Fencing 基于译码阶段的微码自定义，它只适用于使用微码
+的处理器。
+
+Conditional Speculation 定义了安全相关的概念，并将其用于安全冒险检测，
+这个概念可以用于所有可泄露数据的侧信道。对于缓存侧信道，基于缓存命中的
+过滤器和 TPBuf 过滤器结合，性能开销较小。TPBuf 主要用于防御基于共享内
+存的侧信道攻击，而不能防御不利用共享内存的缓存侧信道攻击，这是一个主要
+缺点。
+
+SpectreGuard 是基于隐私数据标记的防御方法，它针对 Spectre 攻击中所有的
+侧信道，而不限于缓存信道。它的设计简单，但是需要软件的支持。
+
+\section{本章总结}
+
+本章介绍了现有的 Meltdown 和 Spectre 的防御方法，重点介绍 Spectre 的防
+御方法，包括软件防御和硬件防御。最后分析了各种防御方案的特性和缺点。