1 files changed, 69 insertions, 4 deletions
diff --git a/chap/chap3.tex b/chap/chap3.tex
index 4540453..d69e788 100644
--- a/chap/chap3.tex
+++ b/chap/chap3.tex
@@ -71,10 +71,75 @@ Google 为 Chrome 浏览器使用了站点隔离（site isolation）技术，使
 
 \subsubsection{SafeSpec}
 
-SafeSpec\supercite{safespec} 提出了一种设计准则：使用临时结构保存推测式执行产
-生的状态，而不影响处理器的主要微架构状态。在实现中，SafeSpec 为缓存和
-TLB 添加了影子结构，推测式执行的指令对缓存和 TLB 修改临时写入至相应的
-影子结构，直到此前分支正确或指令提交时，再将影子结构的数据更新至主结构。
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+SafeSpec\supercite{safespec}提出了一种原则性的方法来保护处理器免受推测
+式执行攻击，同时保留执行推测性执行以从其性能中受益的能力。一般原理（如
+图\ref{fig:safespec}所示）使用临时结构（图中的阴影状态）来保存任何以推
+测方式产生的状态，而不会影响处理器的主要结构（我们在图中称为提交状态）。
+例如，如果推测性加载指令导致加载高速缓存行，而不是将该高速缓存行加载到
+处理器高速缓存中，我们将该行保存在临时结构中。如果稍后对加载指令进行压
+缩，则会将这些效果移除（从提交状态开始的底部路径），不会从错误推测的指
+令中更改缓存，并关闭漏洞。或者，如果指令提交，则将高速缓存行从临时结构
+移动到L1高速缓存并从阴影状态中移除。
+
+\begin{figure}[htbp]
+  \centering
+  \includegraphics[width=0.8\textwidth]{safespec.eps}
+  \caption{SafeSpec 总体设计}
+  \label{fig:safespec}
+\end{figure}
+
+虽然SafeSpec原则上很简单，但必须解决许多与其安全性，复杂性和性能相关的
+问题。我们将在本节的其余部分概述这些问题。
+
+% transient to commit
+有两个选项可用于决定何时将状态从阴影移动到已提交状态。在第一个变量中，
+我们称之为等待分支（WFB），我们可以假设一条指令在它所依赖的所有分支
+（更一般地说，所有预测）都已被解析时不再是推测性的。 WFB阻止两种幽灵的
+变种，它们依赖于错误分支预测;没有任何错误推测的指令移动到已提交状态。
+但是，它不会阻止不依赖于分支预测器的Meltdown。第二个变量等待提交（WFC）
+等待直到导致推测性副作用的指令在将其效果移动到提交状态之前提交，因此也
+会阻止崩溃。我们注意到，根据此定义的重新排序缓冲区是一种阴影状态，只有
+在提交指令时，其数据才会移动到永久状态（架构状态）。
+
+阴影状态组织和大小：如果阴影状态结构太小，则替换推测状态（如果稍后将提
+交此数据，则导致丢失对已提交状态的更新），或者指令必须停止，直到那里在
+发布之前，它是投机结构的空间。因此，从性能的角度来看，应该设计影子结构
+的组织和大小，使得结构可以保持通过在典型工作负载上测量的推测产生的推测
+状态。但是，我们将证明安全考虑因素对投机状态提出了更严格的要求。
+
+减轻瞬态猜测攻击：通过构造安全规范可以防止推测值影响已提交结构的状态，
+这是在已发布的推测攻击中隐蔽地传递数据的途径。但是，它不会在处于推测状
+态的指令之间创建隔离。这为我们称为瞬态推测攻击（TSA）的新型攻击创造了
+可能性。特别是，由于提交的指令可以处于推测状态（在它们的依赖分支在WFB
+中提交之前，或者在指令本身在WFC中提交之前），因此有一个时间窗口，它们
+可以在它们之前与错误指定的指令共享推测状态。被压扁了。如果我们不小心，
+可以在此期间创建一个隐蔽通道，将敏感数据从错误推测的分支传递到将要提交
+的分支，从而允许数据被泄露。
+
+考虑一个尺寸小的阴影结构的例子（比如说一个条目）。然后，读取特权数据的
+恶意推测代码可以使用阴影状态秘密地将其传递给推测代码（将提交的“接收器”
+代码）。例如，它可以替换阴影状态中的条目，导致接收者在提交后注意到其推
+测状态（因为它被替换）的缺失。或者，如果我们在阴影结构已满时阻塞，接收
+器可以检测到其代码执行时间较长。
+
+尽管TSA的严重程度远低于原始攻击，但必须仔细考虑它们以确保无法进行泄漏。
+解决此问题的一种方法是对每个分支的推测状态进行分区，或者对其进行大量调
+整，或者甚至在最坏的情况下，以确保通过阴影状态不发生泄漏。 TSA还可以通
+过在功能单元或其他共享结构上创建争用来秘密地进行通信;这是我们也考虑的
+问题。我们将在第五节讨论如何减轻TSA攻击。
+
+过滤延迟的副作用：当指令在执行过程中被压缩时，会发生SafeSpec的一个问题。
+如果指令已经启动了高延迟操作，例如从内存中读取，我们必须确保在收到内存
+后可以丢弃内存中的响应。 执行的指令推测性地将任何结果状态存储到阴影结
+构。 因此，如果收到长等待时间回复并且没有匹配的事务，我们只是丢弃这些
+值。 然而，也可能希望在系统中较低地过滤这些事务，使得提交的事务直接提
+交，并且压缩的事务在适当的位置被取消。 为了控制此过滤器的大小，我们可
+以在分支粒度中包含一个带有事务和跟踪操作的分支ID。 过滤器还可用于标记
+已提交的分支，以便与其对应的内存响应直接提交到永久结构。
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \subsubsection{InvisiSpec}