remove some gtran

1 files changed, 158 insertions, 237 deletions

diff --git a/chap/chap2.tex b/chap/chap2.tex
index 3224d22..79a7c6f 100644
--- a/chap/chap2.tex
+++ b/chap/chap2.tex
@@ -205,7 +205,7 @@ Foreshadow 对 Intel SGX 所追求的安全模型产生了深远的影响，在�
   \centering
   \includegraphics[width=0.8\textwidth]{addr-trans.eps}
   \caption{CPU 的地址翻译过程和 L1 终端错误的原理：图片的下半部分为文
-    档描述的地址翻译过程，上半部分是微架构的行为。}
+    档描述的地址翻译过程，上半部分是微架构的行为。\supercite{foreshadowNG}}
   \label{fig:addr-tran}
 \end{figure}
 
@@ -293,7 +293,7 @@ Foreshadow 攻击使用在可以直接控制客户机器物理地址和一级缓
   \centering
   \includegraphics[width=0.8\textwidth]{foreshadow-vmm.eps}
   \caption{Foreshadow VMM 的一种使用场景。同一物理核上的虚拟机共享一级
-    缓存，攻击者可以操作其内存访问，读取受害者虚拟机在一级缓存的内容。}
+    缓存，攻击者可以操作其内存访问，读取受害者虚拟机在一级缓存的内容。\supercite{foreshadowNG}}
   \label{fig:foreshadow-vmm}
 \end{figure}
 
@@ -440,32 +440,25 @@ BTB。
 
 %%%%%%%%%%%%%%%%%%%%%% gtran: attack overview %%%%%%%%%%%%%%%%%%%%%%%5
 
-\verb|TODO|: Spectre 攻击的 attack overview
+Spectre 攻击使得受害者程序在推测式地执行在严格按序执行的时不会执行的操
+作，这些操作会通过隐蔽信道将秘密信息泄露给攻击者。
 
-\Fixme: 重新翻译此部分
+Spectre 攻击通常从设置阶段（setup phase）开始，攻击者执行一些用于训练
+处理器的操作，使得处理器在后续阶段执行可被攻击者利用的错误的推测式执行。
+此外，设置阶段中，攻击者可以操作高速缓存状态，从缓存中去除预测的分支所
+依赖的数据，使得推测式执行中的指令足够多，从而可以执行攻击者希望处理器
+执行的指令。在这个阶段，攻击者还可以进行隐蔽信道的准备，如
+Flush+Reload 攻击中清除探测数组对应缓存行的操作。
 
-Spectre 攻击诱使受害者推测性地执行在程序指令的严格序列化有序处理期间不
-会发生的操作，并且通过隐蔽通道将受害者的机密信息泄露给对手。我们首先描
-述利用条件分支错误预测的变体（第IV部分），然后利用对间接分支目标的错误
-预测的变体（第V部分）。
+在第二个阶段，处理器在推测式执行中，将受害者上下文中的秘密信息，传送至
+微架构隐蔽信道。攻击者向受害者通过系统调用等方式发送请求，以出发这个推
+测式执行。攻击者也可以通过自身代码的推测式执行，从同一进程获取敏感信息，
+例如在利用 JIT 编译器的环境中，攻击者可以泄露这个环境中不希望其中执行
+的代码访问的数据。
 
-在大多数情况下，攻击从设置阶段开始，其中攻击者执行操作以误导处理器，以
-便稍后进行可利用的错误推测预测。此外，设置阶段通常包括有助于引发推测性
-执行的步骤，例如操纵高速缓存状态以移除处理器将确定实际控制流所需的数据。
-在设置阶段期间，攻击者还可以准备将​​用于提取受害者信息的隐蔽信道，例如，
-通过执行刷新或驱逐部分Flush + Reload或Evict + Reload攻击。
-
-在第二阶段期间，处理器推测性地执行将机密信息从受害者上下文传送到微架构
-隐蔽信道的指令。这可以通过让攻击者请求受害者执行动作（例如，通过系统调
-用，套接字或文件）来触发。在其他情况下，攻击者可以利用其自身代码的推测
-（错误）执行来从同一进程获取敏感信息。例如，由解释器，即时编译器或“安
-全”语言沙箱化的攻击代码可能希望读取它不应该访问的内存。虽然推测性执行
-可能会通过广泛的隐蔽通道暴露敏感数据，但给出的示例会导致推测性执行首先
-在攻击者选择的地址读取内存值，然后执行内存操作，以暴露出的方式修改缓存
-状态值。
-
-对于最后阶段，恢复敏感数据。对于使用Flush + Reload或Evict + Reload的
-Spectre攻击，恢复过程包括对正在监视的缓存行中的内存地址的访问进行计时。
+最后一个阶段是恢复敏感数据。对于使用 Flush+Reload 的 Spectre 攻击，恢
+复过程的工作之一是对此前清除的缓存行对应的内存地址进行访问计时，从而推
+断出敏感数据。
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -488,139 +481,124 @@ if (x < array1_size)
 
 %%%%%%%%%%%%%%%%%%%%%%% gtran: spectre v1 %%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\verb|TODO|: Spectre 论文中 Spectre v1 的内容
+% \verb|TODO|: Spectre 论文中 Spectre v1 的内容
 
-\verb|TODO|: 解释 Spectre 攻击中这段代码的运行方式，关于在 Javascript 和 eBPF 下的攻击
+% \verb|TODO|: 解释 Spectre 攻击中这段代码的运行方式，关于在 Javascript 和 eBPF 下的攻击
 
-\Fixme: 重新翻译
+% \Fixme: 重新翻译
 
-代码片段以对x的边界检查开始，这对于安全性是必不可少的。特别是，此检查
-可防止处理器读取array1外部的敏感内存。否则，越界输入x可能触发异常或者
-可能导致处理器通过提供x =（要读取的秘密字节的地址）来访问敏感存储器 -
-（array1的基址）。
+这段代码 x 的值做边界检查，确保后续执行代码的安全性，同时该检查也防止
+处理器读取 array1 数组外的敏感内容。否则，越界的数组下标 x 可能触发异
+常，也可以通过构造 x 用于访问敏感数据。
 
 \begin{figure}[htbp]
   \centering
   \includegraphics[width=0.8\textwidth]{spectre_v1.eps}
   \caption{在得出边界检查的正确结果之前，分支预测器使程序从最可能的分
     支目标继续运行，如果预测结果正确，则可以得到性能提升。但是，如果边
-    界检查预测错误，攻击者在一些情形可以泄露秘密数据。}
+    界检查预测错误，攻击者在一些情形可以泄露秘密数据。\supercite{spectre}}
   \label{fig:spectre_v1}
 \end{figure}
 
-图1结合推测执行说明了边界检查的四种情况。在已知边界检查的结果之前，CPU
-通过预测比较的最可能结果来推测性地执行该条件之后的代码。有许多原因可能
-导致边界检查的结果不能立即被知道，例如，在边界检查之前或期间的高速缓存
-未命中，边界检查所需的执行单元的拥塞，复杂的算术依赖性或嵌套的推测执行。
-然而，如图所示，在这些情况下对条件的正确预测导致更快的整体执行。
+图\label{fig:spectre_v1}是边界检查结果和预测的方向的四种组合。在已知边
+界检查的结果之前，处理器预测最可能的结果，推测式地执行边界检查之后的代
+码。导致边界检查的结果不能及时得出的原因很多，如边界检查期间发生缓存缺
+失，缺少空闲的执行单元，存在复杂的数据依赖。在这些情况下，正确预测的可
+以使执行时间更短。
 
-不幸的是，在推测执行期间，边界检查的条件分支可能遵循不正确的路径。在此
-示例中，假设攻击者导致代码运行，使得：
+但是，处理器可以在不正确的路径推测式执行指令。在这个例子中，假设攻击者
+可以控制以如下方式运行：
 
 \begin{itemize}
-\item 选择一个恶意越界的 x 的值，使得 \verb|array1[x]| 指向受害者内存中的某个
-  秘密字节 \verb|k|
-\item \verb|array1_size| 和 \verb|array2| 不在缓存中，但 \verb|k| 在缓存中
+\item 选择一个恶意越界的 \verb|x| 的值，使得 \verb|array1[x]| 指向受害
+  者内存中的某个秘密字节 \verb|k|
+\item \verb|array1_size| 和 \verb|array2| 不在缓存中，但 \verb|k| 在缓
+  存中
 \item 此前的操作中接收到的 \verb|x| 值均有效，使得分支预测器预测 if 为
   真
 \end{itemize}
 
-该高速缓存配置可以自然发生或者可以由对手创建，例如，通过导致驱逐
-\verb|array1_size| 和 \verb|array2|，然后让内核在合法操作中使用秘密密钥。
-
-当上面编译的代码运行时，处理器首先将x的恶意值与array1\_size进行比较。读
-取array1\_size导致高速缓存未命中，并且处理器面临相当大的延迟，直到其值
-可从DRAM获得。特别是如果分支条件或分支之前某处的指令等待未缓存的参数，
-则可能需要一些时间才能确定分支结果。与此同时，分支预测器假定if为真。因
-此，推测执行逻辑将x添加到array1的基地址，并从存储器子系统请求结果地址
-处的数据。该读取是高速缓存命中，并快速返回秘密字节k的值。推测执行逻辑
-然后使用k来计算array2 [k * 4096]的地址。然后它发送一个从内存中读取该地
-址的请求（导致缓存未命中）。虽然从array2读取已经在飞行中，但最终可以确
-定分支结果。处理器意识到它的推测执行是错误的并且重新调整其寄存器状态。
-但是，来自array2的推测性读取以特定于地址的方式影响高速缓存状态，其中地
-址取决于k。
-
-为了完成攻击，攻击者测量array2中的哪个位置被带入缓存，例如，通过Flush
-+ Reload或Prim + Probe。这揭示了k的值，因为受害者的推测执行缓存了
-array2 [k * 4096]。或者，对手也可以使用Evict + Time，即，使用入境值x'
-立即再次调用目标函数，并测量第二次调用所花费的时间。如果array1 [x']等
-于k，那么在array2中访问的位置在缓存中，并且操作趋于更快。
-
-许多不同的情况可能导致使用此变体的可利用泄漏。例如，代替执行边界检查，
-错误预测的条件分支可以检查先前计算的安全结果或对象类型。类似地，推测性
-地执行的代码可以采用其他形式，例如将比较结果泄漏到固定的存储器位置，或
-者可以分布在更大数量的指令上。上述高速缓存状态也比可能需要的更严格。例
-如，在某些情况下，即使缓存了array1\_size，攻击仍然有效，例如，如果在推
-测执行期间应用分支预测结果，即使比较中涉及的值是已知的。根据处理器，也
-可以在各种情况下启动推测执行。其他变体在第VI节中讨论。
-
-我们在多个x86处理器架构上进行了实验，包括Intel Ivy Bridge（i7-3630QM），
-Intel Haswell（i7-4650U），Intel Broadwell（i7-5650U），Intel Skylake
-（Google云端未指定Xeon，i5-6200U，i7- 6600U，i7-6700K），Intel Kaby
-Lake（i7-7660U）和AMD Ryzen。在所有这些CPU上都观察到了Spectre漏洞。在
-32位和64位模式以及Linux和Windows上都观察到类似的结果。一些基于ARM架构
-的处理器也支持推测性执行[7]，以及我们对Qualcomm Snapdragon 835 SoC（带
-有Qualcomm Kyro 280 CPU）和三星Exynos 7420 Octa SoC（带Cortex-A57和
-Cortex-A53）的初始测试CPU）确认这些ARM处理器受到影响。我们还观察到推测
-性执行可以远远超出指令指针。在Haswell i7-4650U上，附录C中的代码（参见
-第IV-B节）可以在'if'语句和访问array1 / array2的行之间的源代码中插入多
-达188条简单指令，这些指令就在下面适合该处理器重排序缓冲区的192个微操作
-（参见第II-B节）。
-
-我们在JavaScript中开发了一个概念验证，并在Google Chrome版本62.0.3202中
-对其进行了测试，该版本允许网站从其运行的进程中读取私有内存。代码如清单
-2所示。
-
-在分支预测器错误引用过程中，索引（通过位操作）设置为范围内值。在最后一
-次迭代中，index被设置为simpleByteArray的越界地址。我们使用变量
-localJunk来确保不优化操作。根据ECMAScript 5.1 Section 11.10 [13]，“|
-0”操作将值转换为32位整数，作为JavaScript解释器的优化提示。与其他优化的
-JavaScript引擎一样，V8执行即时编译以将JavaScript转换为机器语言。虚拟操
-作放在清单2中的代码中，以使simpleByteArray.length存储在本地内存中，以
-便在攻击期间将其从缓存中删除。有关D8的结果反汇编输出，请参见清单3。
-
-由于无法从JavaScript访问clflush指令，我们使用缓存逐出[27,51]，即，我们
-以某种方式访问​​其他存储器位置，以便之后逐出目标存储器位置。泄漏的结果通
-过probeTable [n * 4096]的缓存状态传递，n∈0..255，因此攻击者必须驱逐这
-256个缓存行。长度参数（JavaScript代码中的simpleByteArray.length和反汇
-编中的[ebp-0xe0]）也需要逐出。 JavaScript不提供对rdtscp指令的访问，并
-且Chrome故意降低其高分辨率计时器的准确性以使用performance.now（）[62]
-来阻止定时攻击。但是，HTML5的Web Workers功能使创建一个单独的线程变得简
-单，该线程反复递减共享内存位置中的值[24,60]。这种方法产生了一个提供足
-够分辨率的高分辨率计时器。
-
-作为利用条件分支的第三个例子，我们开发了一个可靠的概念验证，它通过滥用
-eBPF（扩展BPF）接口从未修改的Linux内核泄漏内核内存，而没有针对Specter
-的补丁。 eBPF是一个基于伯克利数据包过滤器（BPF）[49]的Linux内核接口，
-可用于各种目的，包括根据数据包内容过滤数据包。 eBPF允许非特权用户在内
-核的上下文中触发解释或JIT编译以及随后执行用户提供的，内核验证的eBPF字
-节码。攻击的基本概念类似于针对JavaScript的攻击概念。
-
-在此次攻击中，我们仅将eBPF代码用于推测性执行的代码。我们在用户空间中使
-用本机代码来获取隐藏的信道信息。这与上面的JavaScript示例不同，后者的两
-个函数都是用脚本语言实现的。为了推测性地访问用户空间内存中依赖于机密的
-位置，我们对内核内存中的数组执行推测性的越界内存访问，其索引足够大，以
-便访问用户空间内存。概念验证假定目标处理器不支持超级用户模式访问保护
-（SMAP）。但是，没有这种假设的攻击也是可能的。它在Intel Xeon Haswell
-E5-1650 v3上进行了测试，它在默认解释模式和eBPF的非默认JIT编译模式下都
-可以使用。在高度优化的实现中，我们能够在此设置中泄漏高达2000B / s。它
-还在AMD PRO A8-9600 R7处理器上进行了测试，它只能在非默认的JIT编译模式
-下工作。我们将调查原因留给未来的工作。
-
-eBPF子系统管理存储在内核内存中的数据结构。用户可以请求创建这些数据结构，
-然后可以从eBPF字节码访问这些数据结构。为了强制执行这些操作的内存安全性，
-内核存储与每个此类数据结构相关联的一些元数据，并对此元数据执行检查。特
-别地，元数据包括数据结构的大小（在创建数据结构时设置一次并用于防止越界
-访问）以及加载到内核中的eBPF程序的引用数量。引用计数跟踪引用数据结构的
-多少eBPF程序正在运行，确保不释放属于数据结构的内存
-加载的eBPF程序引用它。
-
-我们通过滥用错误共享来增加边界检查的延迟与eBPF管理的阵列的长度。内核将
-数组长度和引用计数存储在同一缓存行中，允许攻击者将包含数组长度的缓存行
-移动到处于Modified状态的另一个物理CPU核心（参见[16,53]）。这是通过加载
-和丢弃引用另一个物理内核上的eBPF阵列的eBPF程序来完成的，这会导致内核在
-另一个物理内核上递增和递减阵列的引用计数器。这种攻击在Haswell CPU上实
-现了大约5000B / s的泄漏率。
+这样的缓存条件可以由攻击者构造，例如，通过构造访问模式造成
+\verb|array1_size| 和 \verb|array2| 被驱逐出缓存，再使受害者在合法的操
+作中使用秘密 \verb|k|.
+
+在这种条件下，这段代码运行时，处理器比较恶意的 \verb|x| 和
+\verb|array1_size|。读取 \verb|array1_size| 导致高速缓存缺失，从而产生
+很大的延迟，需要处理器从主存中获得这个值，才可以产生分支结果。同时，分
+支预测器预测 if 中的条件为真，因此在推测式执行中，处理器访问
+\verb|array1[x]|，此时缓存命中，获得秘密 \verb|k| 的值，然后用它计算
+\verb|array2[k*4096]| 的地址，再从存储系统发出读取这个地址的请求。当分
+支结果在此之后确定时，处理器从错误的推测式执行恢复。但是推测式执行中读
+取 \verb|array2| 的行为影响了缓存状态，而且读取的地址依赖于秘密
+\verb|k|.
+
+攻击者通过测量 \verb|array2| 中的哪个位置在缓存中，可以推断出 \verb|k|
+的值，因为受害者在推测式执行中将 \verb|array2[k*4096]| 带入了缓存。
+
+这种攻击变体可以用在其他场景下，例如分支的条件可以是类型检查，推测式执
+行的代码可以将一个比较结果泄露到一个固定的地址。上述缓存状态在限制更多
+的情形，如 \verb|array1_size| 在缓存中时，攻击也可能可以进行。
+
+这种攻击已经在 Intel, AMD 的多个处理器微架构，和一些支持推测式执行的
+ARM 处理器上进行验证，确认它们受 Spectre v1 的影响。
+
+除了使用原生的机器指令，利用 JavaScript 和 Linux 内核的 eBPF 的 JIT 编
+译器也可以进行 Spectre 攻击。
+
+%% 我们在JavaScript中开发了一个概念验证，并在Google Chrome版本62.0.3202中
+%% 对其进行了测试，该版本允许网站从其运行的进程中读取私有内存。代码如清单
+%% 2所示。
+
+%% 在分支预测器错误引用过程中，索引（通过位操作）设置为范围内值。在最后一
+%% 次迭代中，index被设置为simpleByteArray的越界地址。我们使用变量
+%% localJunk来确保不优化操作。根据ECMAScript 5.1 Section 11.10 [13]，“|
+%% 0”操作将值转换为32位整数，作为JavaScript解释器的优化提示。与其他优化的
+%% JavaScript引擎一样，V8执行即时编译以将JavaScript转换为机器语言。虚拟操
+%% 作放在清单2中的代码中，以使simpleByteArray.length存储在本地内存中，以
+%% 便在攻击期间将其从缓存中删除。有关D8的结果反汇编输出，请参见清单3。
+
+%% 由于无法从JavaScript访问clflush指令，我们使用缓存逐出[27,51]，即，我们
+%% 以某种方式访问​​其他存储器位置，以便之后逐出目标存储器位置。泄漏的结果通
+%% 过probeTable [n * 4096]的缓存状态传递，n∈0..255，因此攻击者必须驱逐这
+%% 256个缓存行。长度参数（JavaScript代码中的simpleByteArray.length和反汇
+%% 编中的[ebp-0xe0]）也需要逐出。 JavaScript不提供对rdtscp指令的访问，并
+%% 且Chrome故意降低其高分辨率计时器的准确性以使用performance.now（）[62]
+%% 来阻止定时攻击。但是，HTML5的Web Workers功能使创建一个单独的线程变得简
+%% 单，该线程反复递减共享内存位置中的值[24,60]。这种方法产生了一个提供足
+%% 够分辨率的高分辨率计时器。
+
+%% 作为利用条件分支的第三个例子，我们开发了一个可靠的概念验证，它通过滥用
+%% eBPF（扩展BPF）接口从未修改的Linux内核泄漏内核内存，而没有针对Specter
+%% 的补丁。 eBPF是一个基于伯克利数据包过滤器（BPF）[49]的Linux内核接口，
+%% 可用于各种目的，包括根据数据包内容过滤数据包。 eBPF允许非特权用户在内
+%% 核的上下文中触发解释或JIT编译以及随后执行用户提供的，内核验证的eBPF字
+%% 节码。攻击的基本概念类似于针对JavaScript的攻击概念。
+
+%% 在此次攻击中，我们仅将eBPF代码用于推测性执行的代码。我们在用户空间中使
+%% 用本机代码来获取隐藏的信道信息。这与上面的JavaScript示例不同，后者的两
+%% 个函数都是用脚本语言实现的。为了推测性地访问用户空间内存中依赖于机密的
+%% 位置，我们对内核内存中的数组执行推测性的越界内存访问，其索引足够大，以
+%% 便访问用户空间内存。概念验证假定目标处理器不支持超级用户模式访问保护
+%% （SMAP）。但是，没有这种假设的攻击也是可能的。它在Intel Xeon Haswell
+%% E5-1650 v3上进行了测试，它在默认解释模式和eBPF的非默认JIT编译模式下都
+%% 可以使用。在高度优化的实现中，我们能够在此设置中泄漏高达2000B / s。它
+%% 还在AMD PRO A8-9600 R7处理器上进行了测试，它只能在非默认的JIT编译模式
+%% 下工作。我们将调查原因留给未来的工作。
+
+%% eBPF子系统管理存储在内核内存中的数据结构。用户可以请求创建这些数据结构，
+%% 然后可以从eBPF字节码访问这些数据结构。为了强制执行这些操作的内存安全性，
+%% 内核存储与每个此类数据结构相关联的一些元数据，并对此元数据执行检查。特
+%% 别地，元数据包括数据结构的大小（在创建数据结构时设置一次并用于防止越界
+%% 访问）以及加载到内核中的eBPF程序的引用数量。引用计数跟踪引用数据结构的
+%% 多少eBPF程序正在运行，确保不释放属于数据结构的内存
+%% 加载的eBPF程序引用它。
+
+%% 我们通过滥用错误共享来增加边界检查的延迟与eBPF管理的阵列的长度。内核将
+%% 数组长度和引用计数存储在同一缓存行中，允许攻击者将包含数组长度的缓存行
+%% 移动到处于Modified状态的另一个物理CPU核心（参见[16,53]）。这是通过加载
+%% 和丢弃引用另一个物理内核上的eBPF阵列的eBPF程序来完成的，这会导致内核在
+%% 另一个物理内核上递增和递减阵列的引用计数器。这种攻击在Haswell CPU上实
+%% 现了大约5000B / s的泄漏率。
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -663,7 +641,7 @@ Spectre v2 利用间接转移的推测式执行，用于预测间接转移的主
   \caption{转移预测器在攻击者控制的上下文 A 中训练。在上下文 B 中，转移
     预测器根据在上下文 A 中的训练结果进行预测，导致处理器跳转至攻击者选
     择的目标地址处进行推测式执行，该目标地址处存放着受害者地址空间中
-    的 Spectre组件。}
+    的 Spectre组件。\supercite{spectre}}
   \label{fig:spectre_v2}
 \end{figure}
 
@@ -773,73 +751,23 @@ Prime+Probe 方式进行 Meltdown 和 Spectre 攻击的形式。通过利用缓�
 
 \Fixme: 重新翻译此内容
 
-迄今为止，在JavaScript [48]和本机代码[15,48,58,75]中已经证明了幽灵攻击，
-但是任何允许足够精确的定时测量和某种形式的代码执行的环境都可能实现这些
-攻击。对英特尔SGX飞地的攻击表明，飞地也容易受到幽灵攻击[15]。但是，有
-数十亿的设备从不运行任何攻击者控制的代码，即没有JavaScript，没有本机代
-码，并且目标系统上没有其他形式的代码执行。到目前为止，这些系统被认为可
-以安全地抵御此类攻击。事实上，供应商确信这些系统仍然是安全的，并建议不
-要对这些设备采取任何措施[42]。
-
-在本文中，我们提出NetSpectre，一种基于Spectre变体1的新攻击，不需要攻击
-者控制的代码
-设备，从而影响数十亿设备。与本地Spectre攻击类似，我们的远程攻击要求目
-标代码中存在Spectre小工具。我们展示了在暴露的网络接口或API中包含所需
-Spectre小工具的系统可能受到我们的通用远程Specter攻击的攻击，允许通过网
-络读取任意内存。攻击者只向受害者发送一系列精心设计的请求，并测量从受害
-者的记忆中泄漏秘密值的响应时间。
-
-我们表明，内存访问延迟通常可以反映在网络请求的延迟中。因此，我们证明了
-攻击者可以通过测量和平均大量测量来远程区分特定高速缓存行上的高速缓存命
-中和未命中。基于此，我们实施了第一个访问驱动的远程缓存攻击，一个名为
-Thrash + Reload的Evict + Reload的远程变体。我们的远程Thrash + Reload攻
-击是先前对加密算法的远程缓存定时攻击的重大飞跃[1,5,11,16,46,82]。我们
-推动这种技术将现有的Spectre攻击改造为基于网络的场景。此NetSpectre变体
-每小时可从易受攻击的目标系统泄漏15位。
-
-通过利用基于AVX2指令执行时间的先前未知的侧通道，我们还演示了第一个完全
-不依赖于缓存隐藏通道的Spectre攻击。我们基于AVX的隐蔽通道实现了每秒125
-字节的本机代码性能，错误率为0.58％。通过在我们的NetSpectre攻击中使用此
-隐蔽通道而不是缓存隐藏通道，我们可以实现更高的性能。由于不再需要高速缓
-存驱逐，因此我们将局域网中目标系统的泄漏速度提高到每小时60位。在Google
-云中，我们每小时可以从另一台独立虚拟机泄漏大约3位。
-
-我们证明使用先前忽略的小工具可以在远程攻击中破坏地址空间布局随机化。
-地址空间布局随机化（ASLR）是当今部署在大多数系统上的防御机制，几乎所有
-地址都是随机的。具有本地代码执行功能的攻击者可以轻松绕过ASLR，因为ASLR
-主要用于防御远程攻击
-但不是本地攻击。因此，到目前为止，Spectre攻击的许多较弱的小工具都被忽
-略了，因为它们不允许泄漏实际数据，而只是泄漏地址信息。但是，转向远程攻
-击情形，这些较弱的小工具变得非常强大。
-
-幽灵小工具可能比以前的工作更加通用。这不仅体现在我们在远程ASLR中断时使
-用的较弱的小工具，而且我们提出的价值阈值技术更是如此。值阈值不使用典型
-的位选择和内存参考机制，如之前的Spectre攻击所示。相反，价值阈值通过使
-用类似于二元搜索的分而治之的方法直接利用比较中的信息泄漏。
-
-NetSpectre标志着从本地攻击到远程攻击的范式转变。这显着扩大了范围并增加
-了受影响设备的数量。特别是，Spectre攻击还必须被视为对不运行任何不受信
-任的攻击者控制代码的设备的安全性的威胁。这表明反措施也必须适用于以前认
-为安全的这些设备。我们提出了Retpolines [77]的新替代品，它具有更清晰的
-结构。关于幽灵攻击和幽灵缓解的未来研究面临着我们概述的一系列挑战。这些
-挑战表明，目前的防御措施只能是临时解决方案，因为它们只能解决症状而不解
-决问题的根本原因。
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
-
-%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\verb|TODO|: NetSpectre 的 attack overview
-
-\Fixme: 重新翻译
-
-在知道实际条件之前，CPU预测条件的最可能结果，然后继续相应的代码路径。
-有几个原因导致在评估时不知道条件的结果，例如条件的部分缓存未命中，尚未
-满足的复杂依赖性，或者所需执行单元中的瓶颈。通过隐藏这些延迟，如果条件
-被正确预测，推测执行会导致更快的整体执行。错误预测条件的中间结果根本不
-会提交到架构状态，并且有效性能类似于处理器永远不会执行任何操作然而，在
-推测性执行期间发生的微体系结构状态的任何修改（例如高速缓存状态）都不会
-被还原。
+NetSpectre\supercite{netspectre} 是通过网络进行的 Spectre 攻击，使得
+Spectre 攻击可以用于不运行攻击者控制的代码的系统上，从而更多的设备受到
+Spectre 攻击的影响。
+
+和本地 Spectre 攻击类似，远程的 Spectre 攻击需要受害者存在 Spectre 组
+件代码，当这些代码可以通过网络接口调用时，攻击者可以向受害者发送一系列
+精心构造的请求，通过测量相应时间，泄露受害者内存中的秘密数据。
+
+访问存储器的延迟可以反映在网络请求的延迟中，因此攻击者可以通过大量的测
+量，远程地区分缓存是否命中。因此，通过使用 Thrash+Reload，一种基于
+Evict+Reload 的远程缓存攻击方式，将 Spectre 攻击用于网络场景，可以每小
+时从目标系统泄露 15 比特数据。通过使用基于 AVX2 指令执行时间的侧信道，
+可以在 NetSpectre 中获得更高的性能，在局域网中可以每小时泄露 60 比特。
+通过使用 NetSpectre 攻击，攻击者可以破坏远程系统中部署的地址空间布局随
+机化（ASLR）防御机制。
+
+%
 
 由于我们的NetSpectre攻击是通过网络安装的，因此受害设备需要攻击者可以访
 问的网络接口。攻击者必须能够向受害者发送大量网络数据包。但是，这些不一
@@ -862,37 +790,37 @@ NetSpectre不会跨越进程边界，而是通过将有效和无效值交替地�
 据包时执行的函数的一部分。我们假设x是攻击者控制的，例如，包头中的字段
 或某些API的索引。此代码构成我们的泄漏小工具。
 
+\begin{figure}[htbp]
 \begin{minted}{C}
 if (x < bitstream_length)
   if (bitstream[x])
     flag = true;
 \end{minted}
+\caption{NetSpectre 的一个泄露组件}
+\label{fig:netspectre_leak}
+\end{figure}
+
+为了在远程攻击中使目标系统在推测式执行中改变微架构状态，攻击者采用原始
+Spectre 的方法。为了触发远程系统的推测式执行，攻击者进行以下操作：
 
-  代码片段以x的绑定检查开始，这是开发安全软件时的最佳实践。特别是，该
-  检查防止处理器读取比特流之外的敏感存储器。否则，越界输入x可能触发异
-  常或者可能通过提供x =（要读取的秘密位的地址） - （比特流的基地址）来
-  使处理器访问敏感存储器。
+\begin{enumerate}
+\item 攻击者发送多个网络数据包，使得攻击者选择的 x 值总是在边界内，训
+  练分支预测器在后续执行此边界检查的分支时，预测 x 在边界内
+\item 攻击者发送一个数据包，使得 x 越界，\verb|bitstream[x]| 是目标系
+  统中的一个秘密数据位
+\item 分支预测器预测边界检查结果为真，推测式执行存储器的访问
+\end{enumerate}
 
-  为了利用远程攻击中推测性执行期间的微体系结构状态变化，攻击者必须适应
-  原始的幽灵攻击。攻击者可以远程诱导推测性执行，如下所示：
+在图\ref{fig:netspectre_leak}的代码中，虽然 flag 的值没有被修改，但是
+flag 的缓存状态会发生变化。如果 \verb|bitstream[x]| 为 1,则 flag 会进
+入缓存，通过 flag 的缓存状态，可以推断 \verb|bitstream[x]| 的值。
 
-  （1）攻击者发送多个网络数据包，使得攻击者选择的x值总是在边界内。这会
-  训练分支预测器，增加分支预测器预测比较结果为真的机会。
-  （2）攻击者发送一个数据包，其中x超出界限，使得比特流[x]是目标存储器
-  中的一个秘密位。
-  （3）根据条件的最近分支结果，分支预测器假定边界检查为真，并且推测性
-  地执行存储器访问。
+传输组件更简单，它只需要在一个操作中使用 flag，它的执行时间取决于 flag
+的缓存状态，例如，最简单的一个传输组件是直接返回 flag 的值。由于传输组
+件的响应时间取决于 flag 的缓存状态，因此可以泄露秘密数据位
+\verb|bitstream[x]| 的值。
 
-  虽然在解决了条件的正确结果后未提交架构状态的更改，但不会还原微架构状
-  态的更改。在清单1的代码中，这意味着虽然flag的值没有改变，但是flag的
-  缓存状态确实发生了变化。仅当设置了比特流[x]处的秘密比特时，才缓存标
-  志。
 
-  传输小工具更简单，因为它只需要在任意操作中使用标志。因此，小工具的执
-  行时间将取决于标志的高速缓存状态。在最简单的情况下，传输小工具只返回
-  flag的值，该值由泄漏小工具设置。由于标志的架构状态（即其值）对于越界
-  x不会改变，因此它不会泄露秘密信息。但是，发送小工具的响应时间取决于
-  标志的微体系结构状态（即，是否被高速缓存），这确实泄漏了一个秘密位。
 
   为了完成攻击，攻击者测量每个秘密位泄漏的响应时间。由于响应时间的差异
   在纳秒范围内，攻击者需要对大量测量进行平均以获得具有可接受置信度的秘
@@ -908,17 +836,10 @@ if (x < bitstream_length)
 \begin{figure}[htbp]
   \centering
   \includegraphics[width=0.8\textwidth]{netspectre.eps}
-  \caption{NetSpectre 的泄露组件和传输组件}
-  \label{fig:spectre_v2}
+  \caption{NetSpectre 的泄露组件和传输组件\supercite{netspectre}}
+  \label{fig:netspectre_gadgets}
 \end{figure}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-
-NetSpectre 可以在局域网，或者 Google cloud 等云平台中使用。利用
-Evict+Reload 缓存信道，每小时可以泄露 15 比特。利用基于 AVX 的隐蔽信道，
-可以每小时泄露 60 比特。
-
 \subsection{SgxPectre}
 
 SgxPectre \supercite{sgxpectre} 将 Spectre 攻击用于泄露 Intel SGX 环境