Grand Schemozzle：幽灵(Spectre)依旧

幽灵V1硬件缺陷一般以允许通过推测执行绕过数组边界检查作为特征。如果这是真的，那么它将不会是这一类漏洞所允许的诡计的全部范围。为表明这个事实，就需要看一下"SWAPGS 漏洞"，由CVE-2019-1125开始广为人知，也被linux内核解决它的开发组人员称作"Grand Schemozzle"

Segment(段)差不多是可以追溯到x86时代最早起的架构遗迹，在很大程度上，他没有在64位世界留存下来。这就是说，少量的Segment还存在于特定的任务；那些还包含GS和FS的任务。当前Linux系统对GS最普遍的应用是为thread-local或cpu-local存储；在内核，GS片段指向per-cpu区域，用户态是允许使用它自己的GS的，arch_prctl()系统调用可以被用于修改这个值。

正如人们所预料，内核需要注意使用自己的GS指针而不是用户空间搞出的指针。x86架构乖乖的提供了一个指令，SWAPGS，来使其相对容易。在进入内核，一个SWAPGS指令将会交换当前GS段指针为一个特定值(MSR中的)；回到用户态之前又会执行SWAPGS，将用户态的GS值换回去。一些小心放置的SWAPGS指令将会因此防止内核运行别的GS指针的下的东西。

可能有人会想，并不是所有进入内核代码的入口都是来自用户态。运行SWAPGS时，如果系统已经运行在内核态的话，是会出问题的，因此内核中的实际代码大多数情况下都是：

if(!in_kernel_mode()) SWAPGS

而这就是出现问题的点了。如果上述代码被预测运行，处理器将会对于是否执行SWAPGS做出错误的决定，进而运行错误的GS段指针。两种方向的推测执行都可能导致错误：CPU推测是用户态，将会直接用用户态GS执行而不SWAPGS，而如果系统已经是内核态了，CPU却可能会推测错误，然后执行SWAPGS，因此用户态GS值被推测执行；系统已经在内核态了，就会不执行SWAPGS。无论哪种方式，随后的per-cpu数据的引用都会推测重映射到一个用户态的地址。这就通过普通的侧信道技术的方式制造了数据泄露。

那看起来会是一个到内核数据结构的开放的通道，但是有一些限制。仅有Intel处理器会执行SWAPGS推测，因此已经在内核态的情况仅限于这些处理器。但是当从用户态进入，缺少必要的SWAPGS指令可以很明显的从任意处理器推测出。

另一个对于攻击者的障碍是：尽管arch_prctl()可以被非特权代码用来设置GS指针，但是这个地址是仅限于用户空间的。这并不能拦截攻击，但是可以使其更困难：一个攻击者必须找到用GS加载值的内核代码，然后用这个值作为依次取消引用的指针。就像JoshPoimboeuf在合入主线的缓解补丁中写的：

It's difficult to audit for this gadget in all the handlers, so while there are no known instances of it, it's entirely possible that it exists somewhere (or could be introduced in the future). Without tooling to analyze all such code paths, consider it vulnerable.(很难在所有处理中审批这个小工具，因此尽管没有已知的实例，但很可能已经存在于某处，或者可以在未来引入。没有工具来分析所有这些代码路径，请视其为缺陷。)

使用特权模式访问保护将会阻止此攻击，但是仅在对熔断漏洞免疫的处理器上有效，因此也就有这么多帮助。

同样值得指出的是，这个问题对添加对FSBASE和GSBASE指令的支持有长期影响，FSBASE和GSBASE允许直接从用户态设置GS。这对性能有一堆提升，因此合补丁的压力将会继续，尽管他们会使利用SWAPGS漏洞更容易。

在内核中的缓解则相对简单：序列化(LFENCE)指令被放在确定是否执行SWAPGS的代码路径上；这将会减慢执行速度，这也是为什么pull request都描述其为性能退化部分。在不考虑这些攻击的系统中，新的屏障可以关闭，同所有其他幽灵V1防御部分一起，在command-line加入nospectre_v1即可。

幽灵漏洞之前非常著名，因为大家都认为在很长一段时间内，它将一直影响我们。推测执行和侧信道的结合导致了巨量可能的攻击以及同样难度的证明这些攻击对给定代码体的不可能性。结果就导致我们现在看到的格局，降低系统来防御可能或不可能的攻击；很可能将会与我们共同前进一段时间。。。