add TODO and FIXME

5 files changed, 234 insertions, 32 deletions

diff --git a/chap/chap2.tex b/chap/chap2.tex
index 9a0b39c..0366d03 100644
--- a/chap/chap2.tex
+++ b/chap/chap2.tex
@@ -397,6 +397,11 @@ Spectre 型攻击利用处理器对控制流或数据流的预测，并进行推
 推测式执行这样的 load 指令，它对应 Spectre-STL.
 
 %%%% gtran: branch prediction
+
+\Todo: 关于处理器执行转移指令的背景知识，是否需要？
+
+\Fixme: 需要重新翻译的内容
+
 在推测执行期间，处理器猜测分支指令的可能结果。更好的预测通过增加可成功
 提交的推测性执行操作的数量来提高性能。
 
@@ -435,10 +440,14 @@ BTB。
 
 %%%%%%%%%%%%%%%%%%%%%% gtran: attack overview %%%%%%%%%%%%%%%%%%%%%%%5
 
-幽灵攻击诱使受害者推测性地执行在程序指令的严格序列化有序处理期间不会发
-生的操作，并且通过隐蔽通道将受害者的机密信息泄露给对手。我们首先描述利
-用条件分支错误预测的变体（第IV部分），然后利用对间接分支目标的错误预测
-的变体（第V部分）。
+\verb|TODO|: Spectre 攻击的 attack overview
+
+\Fixme: 重新翻译此部分
+
+Spectre 攻击诱使受害者推测性地执行在程序指令的严格序列化有序处理期间不
+会发生的操作，并且通过隐蔽通道将受害者的机密信息泄露给对手。我们首先描
+述利用条件分支错误预测的变体（第IV部分），然后利用对间接分支目标的错误
+预测的变体（第V部分）。
 
 在大多数情况下，攻击从设置阶段开始，其中攻击者执行操作以误导处理器，以
 便稍后进行可利用的错误推测预测。此外，设置阶段通常包括有助于引发推测性
@@ -475,6 +484,13 @@ if (x < array1_size)
 
 
 %%%%%%%%%%%%%%%%%%%%%%% gtran: spectre v1 %%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\verb|TODO|: Spectre 论文中 Spectre v1 的内容
+
+\verb|TODO|: 解释 Spectre 攻击中这段代码的运行方式，关于在 Javascript 和 eBPF 下的攻击
+
+\Fixme: 重新翻译
+
 代码片段以对x的边界检查开始，这对于安全性是必不可少的。特别是，此检查
 可防止处理器读取array1外部的敏感内存。否则，越界输入x可能触发异常或者
 可能导致处理器通过提供x =（要读取的秘密字节的地址）来访问敏感存储器 -
@@ -602,9 +618,10 @@ eBPF子系统管理存储在内核内存中的数据结构。用户可以请求�
 和丢弃引用另一个物理内核上的eBPF阵列的eBPF程序来完成的，这会导致内核在
 另一个物理内核上递增和递减阵列的引用计数器。这种攻击在Haswell CPU上实
 现了大约5000B / s的泄漏率。
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\verb|TODO|: Spectre v1.1的内容，需要更详细地解释攻击原理
 
 推测式缓冲区溢出（Speculative Buffer Overflow）
 \supercite{spec-buffer-overflow} 是 Spectre-PHT 的另一种形式。处理器存
@@ -669,6 +686,11 @@ Spectre v2 利用间接转移的推测式执行，用于预测间接转移的主
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\verb|TODO|: Spectre 的论文中关于 Spectre v2 一节的剩余内容，一直到实验结果部
+分
+
+\Fixme: 重新翻译以下内容
+
 许多其他攻击是可能的，这取决于对手所知道或控制的状态，对手所寻求的信息
 所在的位置（例如，寄存器，堆栈，内存等），对手控制推测执行的能力，指令
 序列可用于形成小工具，以及哪些渠道可能会泄漏来自投机操作的信息。例如，
@@ -744,6 +766,10 @@ Prime+Probe 方式进行 Meltdown 和 Spectre 攻击的形式。通过利用缓�
 
 %%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\verb|TODO|: NetSpectre 的 introduction
+
+\Fixme: 重新翻译此内容
+
 迄今为止，在JavaScript [48]和本机代码[15,48,58,75]中已经证明了幽灵攻击，
 但是任何允许足够精确的定时测量和某种形式的代码执行的环境都可能实现这些
 攻击。对英特尔SGX飞地的攻击表明，飞地也容易受到幽灵攻击[15]。但是，有
@@ -800,6 +826,10 @@ NetSpectre标志着从本地攻击到远程攻击的范式转变。这显着扩�
 
 %%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\verb|TODO|: NetSpectre 的 attack overview
+
+\Fixme: 重新翻译
+
 在知道实际条件之前，CPU预测条件的最可能结果，然后继续相应的代码路径。
 有几个原因导致在评估时不知道条件的结果，例如条件的部分缓存未命中，尚未
 满足的复杂依赖性，或者所需执行单元中的瓶颈。通过隐藏这些延迟，如果条件
diff --git a/chap/chap3.tex b/chap/chap3.tex
index d69e788..ec0f824 100644
--- a/chap/chap3.tex
+++ b/chap/chap3.tex
@@ -10,7 +10,9 @@ Meltdown 和 Spectre 及其多种变体被发现后，研究者提出了多种�
 
 \section{Meltdown型攻击的防御}
 
-Meltdown型攻击利用了瞬时指令可以读取体系结构层次上不可访问的数据，并且用此数据做计算。因此一种防御方式是使体系结构层次上不可访问的数据，在微架构层次上仍然不可访问。
+Meltdown型攻击利用了瞬时指令可以读取体系结构层次上不可访问的数据，并且
+用此数据做计算。因此一种防御方式是使体系结构层次上不可访问的数据，在微
+架构层次上仍然不可访问。
 
 KAISER\supercite{kaiser}是一种已经部署在 Linux 内核上的一种防御
 Meltdown 攻击的方案。它的作用是在用户空间中去除内核空间的地址映射，使
@@ -33,6 +35,8 @@ Intel 和 AMD 都提出了在分支指令后插入 lfence 指令阻止推测式�
 为一条串行化指令使用，可以在 lfence 指令提交前阻止新的指令执行，从而阻
 止了程序在推测式执行中对秘密数据进行操作。
 
+\Todo: 增加 SLH,retpoline,index masking 相关的代码
+
 由于 lfence 性能开销大，LLVM提出推测式装载指令加固（Speculative
 Load Hardening）\supercite{spec-load-hardening} 技术，它的作用是在指令
 流中添加数据相关，使得装载指令使用的地址依赖于分支结果。
@@ -55,7 +59,7 @@ Webkit 还使用了指针投毒（pointer poisoning）的方式，它考虑分�
 则得到的指针会指向一个程序无法访问的内存区域。通过这种方法，程序在推测
 式执行中无法通过这种指针访问到程序中的数据，从而避免了秘密数据的泄露。
 
-% site isolation, FIXME: needs citing
+% site isolation, \Fixme: needs citing
 Google 为 Chrome 浏览器使用了站点隔离（site isolation）技术，使得浏览
 器用不同的进程访问不同的网站，从而攻击者无法通过用 Javascript 通过侧信
 道攻击获取另一站点相关的数据。
@@ -73,6 +77,11 @@ Google 为 Chrome 浏览器使用了站点隔离（site isolation）技术，使
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% gtran %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\Todo: SafeSpec III. SAFESPEC :LEAKAGE - FREE SPECULATION 一章，包含一
+些设计选择
+
+\Fixme: 需要重新翻译
+
 SafeSpec\supercite{safespec}提出了一种原则性的方法来保护处理器免受推测
 式执行攻击，同时保留执行推测性执行以从其性能中受益的能力。一般原理（如
 图\ref{fig:safespec}所示）使用临时结构（图中的阴影状态）来保存任何以推
@@ -139,17 +148,27 @@ SafeSpec\supercite{safespec}提出了一种原则性的方法来保护处理器�
 以在分支粒度中包含一个带有事务和跟踪操作的分支ID。 过滤器还可用于标记
 已提交的分支，以便与其对应的内存响应直接提交到永久结构。
 
+\Todo: SafeSpec for caches and TLB
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \subsubsection{InvisiSpec}
 
 %%%%%% gtran %%%%%%
+
+\Todo: InvisiSpec introduction, 去掉最前面的背景介绍部分
+
+\Fixme: 重新翻译
+
 在本文中，我们提出了InvisiSpec，这是一种通过在数据缓存层次结构中使推测不可见来抵御多处理器中的硬件推测攻击的新策略。目标是通过多处理器数据高速缓存层次结构来阻止微架构隐蔽和侧通道，这是由于推测性负载 - 例如，源自高速缓存集占用，线路替换信息和高速缓存一致性状态的信道。我们希望不仅防止基于分支机构推测的类似幽灵的攻击;我们还希望防止任何投机负载可能构成威胁的未来攻击。
 
 InvisiSpec的微架构基于两种机制。首先，不安全的推测性加载将数据读入新的推测缓冲区（SB）而不是缓存中，而不修改缓存层次结构。 SB中的数据不会观察缓存一致性事务，这可能导致丢失内存一致性违规。我们的第二种机制解决了这个问当推测性负载最终是安全的时，InvisiSpec硬件通过将其重新发送到内存系统并将数据加载到高速缓存中使其对系统的其余部分可见。在此过程中，如果InvisiSpec认为负载可能违反了内存一致性，InvisiSpec会验证负载首次读取的数据是否正确 - 如果数据不正确则压缩负载。
 
 % memory consistency
 
+\Todo: InvisiSpec 考虑了内存模型，下面是关于 TSO 和 RC 的介绍
+
+\Fixme: 重新翻译
+
 内存一致性模型（或内存模型）指定内核执行内存操作的顺序，并由共享内存系统中的其他内核观察[10]。当商店退休时，其数据将存入写缓冲区。从那里，当内存一致性模型允许时，数据被合并到缓存中。我们说当数据合并到缓存中时执行存储，并且所有其他核心都可以观察到存储。负载可以在到达ROB头之前从内存中读取。我们说负载是在接收数据时执行的。负载可以从存储器读取并且不按顺序执行 - 即，在ROB中的早期加载和存储之前。无序负载可能导致内存一致性违规，核心通过推测执行的压缩和回滚机制恢复[11]。细节取决于内存模型;我们将在下面描述两种常见模型，我们将其假设为添加InvisiSpec的基线。
 
 总存储顺序（TSO）[12]，[13]是x86架构的内存模型。 TSO禁止所有可观察的加载和存储重新排序，但存储→加载重新排序，即当负载绕过较早的存储到不同的地址时。实现通过确保负载在执行时读取的值在负载退出时保持有效，从而阻止可观察负载→负载重新排序。如果核心接收到负载读取的线路的高速缓存无效请求（或遭受高速缓存驱逐），则通过压缩已执行但尚未退出的负载来维持此保证。通过使用FIFO写入缓冲区来防止存储→存储重新排序，确保存储按程序顺序执行。如果需要，可以通过使用fence指令分隔存储和加载来防止存储→加载重新排序，该指令在完成所有先前的访问之前不会完成。原子指令具有栅栏语义。
@@ -177,6 +196,10 @@ Speculative Store Bypass & 装载指令和更早的存储指令地址别名\tabu
 \hline 
 \end{tabular}
 
+\Todo: InvisiSpec  V: INVISISPEC: THWARTING SPECULATION ATTACKS
+
+\Fixme: 重新翻译以下内容
+
 1）不安全的推测负载：严格地说，任何在到达ROB头部之前启动读取的负载都是推测负载。在这项工作中，我们对可能由于推测而产生安全漏洞的（大）投机负载子集感兴趣。我们称这些负载为Unsafe Speculative Loads（USLs）。作为USL的一组推测性负载取决于攻击模型。
 
 在Spectre攻击模型中，USL是遵循未解决的控制流指令的推测性负载。一旦控制流指令解决，跟随它的USL在分支的正确路径中转换到安全负载 - 尽管它们仍然是推测性的。
@@ -234,22 +257,93 @@ USL执行两个事务 - 一个是首次发布时，一个是验证或公开时�
 如果在两次访问之间，第二个核心通过验证/暴露或安全访问访问该线路，则InvisiSpec使来自第一个核心的LLC-SB的线路无效。这保守地确保LLC-SB不保存陈旧数据。在这种情况下，原始USL的验证或公开事务将从缓存层次结构中的任何位置获取该行的最新副本。
 %%%%%%%%%%%%%%%%%%%
 
-InvisiSpec\supercite{invisispec} 和 SafeSpec 类似，使用一个称为推测式
-执行缓冲区（Speculative Buffer）的结构存放推测式执行的 load 指令从存储
-系统中获取的数据，直到这条指令安全的时候再让它更新缓存。和 SafeSpec 不
-同的是，InvisiSpec 考虑了缓存一致性和存储一致性的问题，在 load 指令确
-认安全之后，增加一个验证的步骤，确认使用没有违反存储一致性。
-
 在 gem5 模拟器下， 使用 SPEC CPU2006 和 PARSEC 对 InvisiSpec 进行评测，
 以 Spectre 为威胁模型，在 TSO 内存模型下，InvisiSpec 平均性能损失为
 21\%，而使用 fence 性能下降 74\%.
 
 \subsubsection{DAWG}
 
-Dynamic Allocated Way Guard(DAWG)\supercite{dawg} 是一种防御缓存侧信道
-攻击的缓存设计。DAWG让不同的程序使用不同的安全域，一个安全域中的程序只
-能使用缓存中的某些路，和 Intel CAT 允许程序在缓存任意一路命中不同，
-DAWG 不允许程序在安全域规定的路之外中发生缓存命中。
+\Todo: DAWG introduction
+
+\Fixme: 重新翻译
+
+在一个设计良好的系统中，攻击者无法在架构上观察到这个秘密，因为秘密应该
+局限于一个保护域，阻止其他程序在架构上观察它。但是，当攻击者可以通过软
+件方式观察执行的副作用时，可能存在漏洞。
+
+进行这种观察的机制称为软件侧信道。必须根据受害者保护域中的活动来调制这
+些信道，即它们的状态改变，并且攻击者必须能够检测那些状态变化。目前，最
+广泛探索的渠道基于共享缓存的状态。例如，如果攻击者观察到地址上的命中，
+则该地址必须已经缓存，这意味着某个方（可能是受害者）最近访问过该地址，
+并且尚未被替换。确定访问是否是命中可以通过测量程序进行特定引用所花费的
+时间来完成。
+
+隐蔽通信信道在不允许通过现有保护机制进行通信的进程之间传输信息。例如，
+当侧信道用于向攻击者传达“秘密”时，攻击将包括受害者保护域内用于访问秘密
+的代码和用于将秘密传递给攻击者的发送器。它们一起形成数据抽头，将根据秘
+密调制信道。由攻击者控制并在受害者保护域之外的接收器将监听信道上的信号
+并对其进行解码以确定该秘密。这在图1中以图示的方式示出。
+
+对RSA的经典攻击依赖于这种情况[9]。具体地，现有RSA代码遵循作为秘密的函
+数的条件执行序列，并且通过根据该执行序列修改指令高速缓存状态而无意地发
+送私有信息。这导致了一个隐蔽的通信，让观察对手确定秘密的位。在这种情况
+下，访问秘密的代码和传送秘密的发送器预先存在于RSA代码中。因此，共享
+icache的攻击者仅需要提供可以解调通过基于缓存标签状态的信道传送的秘密的
+接收器。最近的工作表明，广泛的可行攻击通过共享缓存渗透信息。
+
+最近，多个安全研究人员（例如，[22]，[31]，[35]）已经找到了攻击者在受害
+者中创建新数据管道的方法。这里，攻击者能够在受害者的域中创建数据抽头和
+/或影响数据抽头以访问和传输所选择的秘密。 Spectre和Meltdown利用了这样
+一个事实，即推测性地执行的代码可以完全访问任何秘密。
+
+虽然广泛定义了投机执行，但我们关注的是本文中的控制流量推测。现代处理器
+不按顺序执行指令，只要保留依赖性，就允许下游指令在上游指令之前执行。现
+代无序处理器上的大多数指令也是推测性的，即，它们创建检查点并沿着预测路
+径执行，同时一个或多个先前条件分支正在等待解决。预测被解析为正确丢弃检
+查点状态，而不正确一个强制处理器回滚到检查点并沿正确的路径继续。一段时
+间内执行了错误预测的指令，但不修改架构状态。然而，诸如高速缓存标签状态
+的微体系结构状态由于（不正确的）推测性执行而被修改，从而导致信道被调制，
+这可能允许秘密泄漏。
+
+通过利用错误推测的执行，攻击者可以执行通常无法访问的代码路径，从而绕过
+软件不变量。一个例子是攻击者推测性地执行非法访问秘密的数据抽头代码，并
+在异常发生之前通过微架构副作用引起传输[35]。另一个例子是攻击者强制分支
+预测器状态以鼓励沿着攻击者选择的代码路径的错误推测，这实现了受害者域中
+的数据抽头。因此，有三种创建数据点击的方法：
+1）数据抽头预先存在于受害者的代码中，我们在RSA攻击[9]中描述过。
+2）攻击者明确编程数据点击。 Meltdown [35]就是一个例子。
+3）攻击者合成受害者现有代码中的数据抽头 - 例如幽灵变种[22]，[30]，[31]。
+
+例如，该框架可以应用于除缓存状态之外的侧通道，描述通过分支预测器逻辑或
+TLB状态的泄漏。鉴于对这种新攻击类的变体的研究兴趣越来越浓，我们也想象
+出可以构建数据抽头的新方法。因此，我们希望设计一种针对广泛的当前和未来
+攻击的防御。
+
+已经提出了可以仅在软件中实现的防御机制（例如，[11]，[43]）。不幸的是，
+这些机制看起来非常具有攻击性：例如，编译器分析[43]确定了一些易受幽灵变
+种1影响的代码实例;微码更新或编译器和链接器修复减少了对Spectre Variant
+2的暴露[11]。已经引入了关闭脆弱区域中的推测的指令（例如，[2]），供将来
+的编译器使用。在本文中，我们针对硬件进行了最小程度的修改，以抵御广泛的
+侧通道攻击，包括那些基于推测的攻击，其目标是通过改变缓存状态来消除与渗
+透相关的整个攻击面。
+
+为了防止泄漏，我们需要保护域之间的强隔离，这可以防止任何发送器/接收器
+对共享相同的通道。缓存分区是一种实现隔离的吸引人的机制。不幸的是，设置
+（例如，页面着色[29]，[50]）和方式（例如，英特尔的高速缓存分配技术
+（CAT）[21]，[23]）当今处理器中可用的分区机制要么性能低要么要么不高提
+供隔离。
+
+我们提出了DAWG，动态分配方式保护，一种用于包括高速缓存的集合关联结构的
+安全方式分区的通用机制。 DAWG赋予一组关联结构和保护域概念，以提供强大
+的隔离。与CAT等现有机制不同，DAWG不允许跨保护域点击。这会影响命中路径
+和缓存一致性[42]，DAWG通过对现代操作系统的最小修改来处理这些问题，同时
+将操作系统的攻击面减少到一小部分带注释的部分，其中数据跨越保护域，或者
+域是调整/重新分配。只有在这些少数例程中，DAWG保护才会放松，并且根据需
+要应用其他防御机制，例如投机围栏。我们使用体系结构仿真和实际硬件的组合
+来评估DAWG的性能影响，并与传统的服务质量分区缓存进行比较。我们得出结论，
+DAWG提供了强大的隔离和合理的性能开销。
+
+\Todo: DAWG 的设计
 
 在 zsim 模拟器中使用 SPEC CPU2006, PARSEC, GAPBS 进行模拟，相对于
 Intel CAT，在不同的评测程序和划分方式下，大多数程序性能下降为 4\%\~7\%.
@@ -259,6 +353,40 @@ DAWG 的主要缺点是需要操作系统的支持。此外，DAWG 不能防御
 
 \subsubsection{Context-Sensitive Fencing}
 
+\Todo: CSF introduction
+
+\Fixme: 重新翻译
+
+这项工作提出了上下文敏感的防护，一种针对幽灵的新型微码级防御。防御策略
+的关键组成部分包括：（a）微码定制机制，允许处理器手动将栅栏插入动态指
+令流，以减轻推测性执行的不良副作用，（b）解码器级信息流跟踪（DLIFT）
+）框架，用于识别可能不安全的执行模式以触发微代码定制，以及（c）缓解保
+护分支预测器和返回地址堆栈的缓解措施。
+
+为了在对性能影响最小的情况下执行安全的微码定制，这项工作利用了上下文敏
+感解码（CSD）[68]，这是最近提出的对英特尔（和其他人）微操作转换机制的
+扩展，可实现按需和上下文敏感自定义动态微操作指令流。此外，这项工作还利
+用了CSD提供的重新配置框架，允许操作系统和其他可信实体动态控制通过外科
+手术插入微操作流的投机栅栏的频率，类型和行为，以确保投机安全执行。
+
+这项工作分析了一套显着扩展的围栏，考虑了不同的可能的执法阶段和执法策略。
+特别是，我们引入了一个新的栅栏，可以防止推测性更新缓存状态，同时在指令
+的动态调度中具有最小的干扰。
+
+上下文敏感的防护能够通过基于解码器级信息流跟踪的新型检测机制自动识别网
+格插入点。由于处理器前端通常以比管线的其余部分高得多的速率搅拌指令，因
+此解码器级的信息流跟踪易于频繁过度和不确定的情况。虽然由于栅栏插入的频
+率增加而导致过度拉伸可能会损害性能，但是对于短暂的窗口来说，不确定会破
+坏系统的安全性。通过早期低开销的错误检测和恢复机制解决这些挑战，本文进
+一步确定了解码器级信息流跟踪作为一种有效的攻击检测机制的可行性。
+
+这项工作进一步提出了新的微操作流程，保护分支预测器和返回地址堆栈，防止
+跨不同保护域的错误训练和/或逆向工程。虽然与英特尔提出的间接分支预测器
+屏障（IBPB）指令的精神相似，但这些微操作流程更广泛地应用于更广泛的分支
+预测器和返回地址堆栈，并提供更细粒度的控制。
+
+\Todo: 更详细地介绍 CSF
+
 Context-Sensitive Fencing(CSF)\supercite{context-sensitive-fencing} 是
 一种微码级防御多种类型 Spectre 攻击的方法。它基于 Context-Sensitive
 Decoding (CSD)\supercite{context-sensitive-decoding}，一种微码翻译机制
@@ -319,6 +447,10 @@ SpectrePrime & 条件分支 & 访存\tabularnewline
 
 % the following is from gtran
 
+\Todo: V-B Security Hazard Detection in Issue Queue
+
+\Fixme: 重新翻译
+
 我们设计了基于比特矩阵的安全检测逻辑，如图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]根据以下公式。
@@ -349,6 +481,11 @@ S-Pattern 不匹配，则被认为是安全的。
 
 % gtran
 
+\Todo: V-C cache-hit based hazard filter 和 V-D Trusted Pages Buffer
+based Hazard Filter
+
+\Fixme: 重新翻译
+
 一种简单的危险消除方法是简单地阻止在发布队列中标记有可疑推测标记的所有指令。这样的政策显然会导致性能下降。同时，只有导致高速缓存未命中的内存请求将改变高速缓存内容，并且大多数应用程序表现出良好的时间和空间局部性。受这两个观察的启发，基于缓存命中的危险过滤器被提议用于减少保守地不执行具有可疑推测标记的指令的性能影响。
 
 % hit-based
@@ -392,8 +529,17 @@ S-Pattern 不匹配，则被认为是安全的。
 
 \subsubsection{SpectreGuard}
 
+SpectreGuard\supercite{spectreguard} 是一种软硬件结合防御 Spectre 攻击
+的方法。软件在页表中标记一个页是否存在秘密数据，如果一条指令在推测式执
+行中读取了带标记的页中的数据，处理器则禁止这条指令将读取的值转发至其他
+指令，直到这条指令之前的所有预测都已验证，确认推测式执行正确。
+
 %%% gtran %%%
 
+\Todo: SpectreGuard introduction
+
+\Fixme: 重新翻译
+
 自Spectre披露以来，已经提出了几种基于软件和硬件的缓解策略。基于软件的缓解策略通过手动插入序列化指令[12]或在条件跳转和后续存储器加载指令之间引入其他数据依赖性[7,21]来防止推测。但是，手动识别程序的易受攻击的分支是困难的，而通过编译器自动化保护所有分支会导致过多的性能开销[21]。基于硬件的方法通常通过引入额外的硬件结构来缓冲推测结果来集中隐藏攻击者可观察的微架构状态变化[13,27]。虽然它们不需要手动更改代码，但它们会导致侵入式硬件更改和高性能开销[13,27]。
 
 在本文中，我们提出了SpectreGuard，一种针对幽灵攻击的新型跨层防御。我们的方法是以数据为中心的，因为我们专注于程序的数据而不是代码。我们观察到，对于软件开发人员来说，识别程序的秘密数据（例如，密钥）可能比识别易受攻击的代码块（即，幽灵小工具）更容易，这些代码块可以出现在程序的任何分支中，即使它们不相关处理秘密数据。因此，我们的方法首先要识别敏感的内存块，这些内存块保存秘密数据，并将它们标记为非推测性内存区域。识别的存储区域通过简单的OS /库API被通知给OS，然后由硬件利用以通过低成本的微架构扩展选择性地和有效地防止推测性攻击。
@@ -404,12 +550,6 @@ S-Pattern 不匹配，则被认为是安全的。
   
 %%%%%%%%%%%%%%
 
-
-SpectreGuard\supercite{spectreguard} 是一种软硬件结合防御 Spectre 攻击
-的方法。软件在页表中标记一个页是否存在秘密数据，如果一条指令在推测式执
-行中读取了带标记的页中的数据，处理器则禁止这条指令将读取的值转发至其他
-指令，直到这条指令之前的所有预测都已验证，确认推测式执行正确。
-
 在 gem5 模拟器中用 SPEC CPU2006 评测，如果标记内存的所有页，则
 SpectreGuard 的平均性能开销为 20\%, 而如果标记堆区域，则性能开销减少至
 8\%. 在使用 OpenSSL 的合成基准测试中，如果只标记私钥为秘密数据，则性能
diff --git a/chap/chap4.tex b/chap/chap4.tex
index d6df685..455e2b6 100644
--- a/chap/chap4.tex
+++ b/chap/chap4.tex
@@ -1,4 +1,4 @@
-\chapter{可抵抗Spectre攻击的微架构的设计与实现}\label{sec:mywork}
+\chapter{针对 Spectre 攻击的微架构设计}\label{sec:mywork}
 
 本章讲解本文提出的一种防御 Spectre 攻击的方法，该方法使用动态信息流追
 踪的方法，检测 Spectre 组件指令流中可能泄露秘密数据的访存指令，并使用
@@ -22,6 +22,8 @@ Spectre-RSB 攻击，此方法可以扩展至 Spectre-STL 攻击。攻击者在
 
 \section{基于动态信息流追踪的Spectre检测方法}
 
+\Todo: 这一节是否可以写到3页？
+
 动态信息流追踪（Dynamic Information Flow Tracking）\supercite{dift}是
 一种硬件安全策略，通过识别可疑的信息流，并限制可疑信息的使用，保护程序
 的安全。它最早用于防止攻击者利用缓冲区溢出攻击执行恶意代码，也可以用于
@@ -37,6 +39,12 @@ CSF\supercite{context-sensitive-fencing} 中的译码级信息流追踪框架 DI
 
 本文使用 DIFT 检测 Spectre 组件中泄露数据的 load 指令。详细设计如下：
 
+\Todo: 解释为什么使用这种方法，和其他相似方法（DLIFT, TPBuf, SG(Full)）的比较
+
+\Todo: 增加结构示意图和代码描述
+
+\Todo: 使用更加详细的描述
+
 \begin{itemize}
 \item 为每个物理寄存器添加一位标记，表示这个寄存器的数据是否来自于推测
   式执行中从内存读取的数据
@@ -68,7 +76,19 @@ void victim(size_t x, uint8_t k) {
 问可能泄露 \verb|array1[x]| 的数据。因此，如果一条控制指令依赖于被标记
 的寄存器，则对它进行标记，其后的所有 load 指令都认为不安全。
 
-\section{可抵抗 Spectre 攻击的微架构的实现}
+\Todo: 解释怎样处理以上的情形
+
+\section{使用推测式执行缓冲区}
+
+\Todo: 说明在检测到不安全的访存指令后，推迟它的执行和用 InvisiSpec 的 SpecBuf 执行的区别
+
+\Todo: 为什么只对部分指令使用，对推测式执行中的部分指令使用 InvisiSpec 是否需要修改
+
+\Todo: 本文使用的基于 DIFT 的检测方法和 InvisiSpec 结合
+
+\section{针对 Spectre 攻击的微架构在 gem5 中的实现}
+
+\Todo: 这节介绍怎样在 gem5 中实现我的工作
 
 以下介绍这种可抵抗 Spectre 攻击的微架构在 gem5 模拟器中的实现。首先分
 析 gem5 中乱序执行处理器的实现，然后分别介绍 InvisiSpec 和本文使用的
@@ -76,6 +96,8 @@ DIFT 方案在 gem5 中的实现。
 
 \subsection{gem5 的乱序执行处理器}
 
+\Todo: 做一个 gem5 流水线的示意图？
+
 gem5 的乱序执行处理器实现在 FullO3CPU 类中，它又用类实现类处理器的以下
 流水级：取指（Fetch）、译码（Decode）、重命名（Rename）、发射/执行/回
 写（IEW）、提交（Commit）。
@@ -101,14 +123,20 @@ gem5 的发射、执行和回写三个阶段由一个类 DefaultIEW 实现，它
 gem5 的提交阶段由 DefaultCommit 类实现，它提交 ROB 队列头部的指令，更
 新 ROB 的状态。
 
-\subsection{InvisiSpec 的实现}
+\subsection{InvisiSpec的LSQ的实现}
+
+\Todo: InvisiSpec 所用的 load 指令执行逻辑在 gem5 LSQ 中的实现
 
-% 本文使用 InvisiSpec 执行检测为不安全的 load 指令。相对于阻止该 load 指
-% 令的执行，使用 InvisiSpec 执行该指令，可以使依赖于这个指令的指令可以继
-% 续执行，减少性能损失。以下分析 InvisiSpec 的详细设计，在下一节中分析将
-% xSpectre 检测技术和 InvisiSpec 结合的方法。
+\subsection{推测式执行缓冲区的实现}
 
-% InvisiSpec 使用推测式执行缓冲区保存推测式执行中 load 指令得到的数据，
-% 这部分代码在。
+\Todo: InvisiSpec 的 SpecBuf 在 gem5 中的实现
+
+\subsection{InvisiSpec对缓存一致性协议的修改}
+
+\Todo: InvisiSpec 的 SpecBuf 在 gem5 中的实现
 
 \subsection{动态信息流追踪的实现}
+
+\Todo: 本文所用的 DIFT 方案在 gem5 中的实现，和已有 InvisiSpec 代码的结合
+
+\Todo: 如何添加一个总结性的章节？
diff --git a/chap/chap5.tex b/chap/chap5.tex
index ff1dc0c..05a30ff 100644
--- a/chap/chap5.tex
+++ b/chap/chap5.tex
@@ -134,3 +134,5 @@ victim 在正常执行中无法访问的 X 的值。攻击者先训练 victim �
 些指令的执行，有 15\% 的性能开销，平均性能开销比 InvisiSpec 小。在此基
 础上，用 InvisiSpec 的方案执行这些 load 指令，可以进一步将性能开销减少
 至 8.5\%.
+
+\Todo: 评测结果的分析
diff --git a/thesis.tex b/thesis.tex
index 9325f72..722fb9a 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -50,6 +50,8 @@
 \addbibresource{thesis.bib}
 
 \newcommand{\Fault}[1]{\texttt{\#}#1}
+\newcommand{\Todo}{\textbf{TODO}}
+\newcommand{\Fixme}{\textbf{FIXME}}
 
 \begin{document}
 	% 以下为正文之前的部分，默认不进行章节编号。