LWN: 大麻烦！Spectre继续捣乱

点击上方蓝色“Linux News搬运工”关注我们~

Grand Schemozzle: Spectre continues to haunt

By Jonathan Corbet

对于此前的Spectre v1硬件漏洞，大家通常的理解就是数组越界检查可能会在speculative execution（预测执行）的情况下被绕过，从而产生问题。这个理解没错，不过并不完整，还有其他一些攻击方法，例如CVE-2019-1125 "SWAPGS vulnerability"就展示了这一点。这个CVE在Linux kernel的部分开发者这边被称为“Grand Schemozzle（大麻烦）”。

Segment这个概念其实是早期x86系统上遗留下来的体系结构概念了。在64位时代，其实基本上已经没用了。不过对于某些特殊task来说，还使用了一些segment，包括FS和GS。GS通常用在Linux系统里面来存放thread-local或者CPU-local的数据。在kernel里面，GS segment指向per-CPU数据区域。user space有权限直接使用它自己的GS。arch_prctl()系统调用可以用来修改这个值。

当然，kernel需要注意一定要使用它自己的GS指针，而不是使用user space提供的GS指针。x86架构必备的一条指令SWAPGS，就是用来让这个功能更加简便易用的。每次调入kernel的时候，会有一个SWAPGS指令来把当前的GS segment指针换成一个预设值（存放在CPU状态相关的寄存器里，model-specific register）。在返回user space的时候再执行一次SWAPGS，就能把user-space需要用的GS值恢复回来。这样只要仔细设计SWAPGS指令的调用位置，就能防止kernel使用GS pointer以外的数据。这是大家理想中的行为。

这里有一点要注意，并不是每次进入kernel都是从user space发起的。如果系统本来已经在kernel mode了（内核态），执行SWAPGS指令会让系统混乱。所以这里实际写好的kernel代码在大多数情况下其实是等效于这种写法：

    if (!in_kernel_mode())

    SWAPGS

这里其实就是我们今天讨论的会出错的地方了。如果这个代码也被speculatively executed（预测执行了），那么处理器可能就会判断错误从而执行SWAPGS然后使用错误的GS segment指针了。这里的判断条件很有可能会受预测执行错误影响。如果CPU刚从user space进入kernel，此时它判断错误的话，就会导致放弃SWAPGS，从而导致使用了user-space的GS值。另一种情况下，系统本来已经在kernel mode执行了，CPU可能会预测错误，然后执行了本不该运行的SWAPGS，这样就会导致它错误使用了user-space GS值。总之，这两种情况下，后续的per-CPU数据访问都会访问到user-space控制的一个地址去了，这样恶意程序再利用普通的side-channel攻击方法就可以窃取到数据了。

粗看下来，这样会导致kernel数据结构内容的保护形同虚设，不过其实这种攻击方案还是有不少限制。首先只有Intel处理器才会对SWAPGS进行预测执行，因此上述两种场景之中的第二种，已经在kernel的场景，只有Intel处理器才会有受攻击的风险。不过针对第一种场景，当从user mode切换进入kernel mode时，任何处理器都可能会预测错误跳过SWAPGS。

对攻击者来说还有一个困难，就是arch_prctl()虽然可以在非特权代码（unpriviledged code）里被调用来设置GS指针，不过这个指针必须指向user-space的地址。这一点虽然不能完全避免漏洞，不过还是会让漏洞很难利用：攻击者必须先找到kernel里的某段代码会从GS来获取一个变量并把这个变量作为指针来作为后续访问之用的。Josh Poimboeuf在mainline里合入的保护patch里面也提到：“我们很难审查所有处理函数里面是否有符合这种要求的kernel代码，所以虽然目前我们还没找到这样的例子，但是很有可能真的在某些地方会有这种代码逻辑（或者今后可能会有新的代码使用这种逻辑），如果没有工具能扫描出所有这类代码逻辑的话，就应该认为这是一个受攻击的风险点”。

可以通过使用supervisor mode access prevention机制（Intel新增的SMAP功能）来阻止这种攻击，不过这样一来只有那些不怕Meltdown攻击的处理器可以使用这个功能来做防护，因此这种方案价值不是很大。

此外，还有一个长期在进行的工作，是支持FSBASE和GSBASE指令，它们会允许user space来直接设置GS，kernel无法控制。这个功能会对系统性能提升有很大好处，所以一直有人在希望能合入这个功能到Linux mainline，不过这样的话，类似SWAPGS这种攻击方式对攻击者来说就会更加容易实现了。

在kernel实现的防护补丁逻辑很简单：在需要（或者不需要）执行SWAPGS的代码这里需要确保指令是顺序执行的（利用LFENCE）。当然这会影响代码执行速度，这也是为什么patch set里面开玩笑地提到这些patch是来自“性能恶化部门”。某些系统上并不需要担心这类攻击的，那么就可以通过加一个nospectre_v1命令行选项来把新加的barrier指令都去掉（其他的Spectre v1防护代码也都可以一起去掉）。

Spectre漏洞的名字英文含义是幽灵，给它起这个名字也就是因为我们认为这类问题会伴随我们相当长时间。预测执行（speculative execution）和side channels（侧信道攻击）组合在一起的话会出现许多新类型的攻击方式，并且多数很难从安全防护人员的角度来保证这些攻击是否真实可行（需要有办法能探查出特定模式的代码）。因此，我们现在采取的应对方式（牺牲系统运行性能来预防攻击）很有可能也会伴随我们很长时间。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～