解释Linux提交消息，该消息在POP SS后面加#BP中断（INT3）的补丁/保护

Question

这是参考CVE-2018-8897（与CVE-2018-1087有关），描述如下：在某些或所有操作系统内核的开发中，《英特尔64和IA-32体系结构软件开发人员手册》（SDM）的系统编程指南中的一条语句处理不当，导致MOV SS推迟的#DB异常的行为异常或POP SS，例如Windows，macOS，某些Xen配置或FreeBSD中的特权升级或Linux内核崩溃所证明的那样。MOV到SS和POP SS指令禁止中断（包括NMI），数据断点和单步陷阱异常，直到下一条指令之后的指令边界为止（SDM第3A卷； 6.8.3节）。（禁止的数据断点是由MOV到SS或POP到SS指令本身访问的存储器上的断点。）请注意，调试异常不受中断允许（EFLAGS.IF）系统标志（SDM第3A卷；第2节，第1部分）的禁止。第2.3节）。如果MOV到SS或POP到SS指令之后的指令是SYSCALL，SYSENTER，INT 3等指令，该指令以CPL <3的方式将控制权转移到操作系统，则在将调试转移到CPL <3的情况下会传递调试异常。已经完成。OS内核可能不希望事件发生的顺序如此，因此发生时可能会遇到意外的行为。在阅读有关Linux内核的相关git commit时，我注意到该提交消息指出：x86 / entry / 64：请勿将IST条目用于#BP堆栈＃BP / int3没有IST值得的。我们不允许kprobes出现在内核中少数以无效堆栈运行于CPL0的地方，而32位内核永远将正常中断门用于#BP。此外，在内核模式下，我们不允许将kprobes放在有userg的地方，因此“偏执狂”也是不必要的。鉴于该漏洞，我试图了解提交消息中的最后一句话。我了解到，IST条目是指中断堆栈表中的（据说）“已知良好”堆栈指针之一，该指针可用于处理中断。我还了解到#BP指的是断点异常（与等效INT3），而kprobes是调试机制，据称该机制仅在环0（CPL0）特权级别的内核中运行。但是我在接下来的部分中完全迷失了，这可能是因为“ usergs”是一个拼写错误，而我只是缺少了预期的内容：此外，在内核模式下，我们不允许将kprobes放在有userg的地方，因此“偏执狂”也是不必要的。这句话是什么意思？

Answer 1

usergs指的是x86-64 swapgs指令，该指令gs与内部保存的GS值交换给内核，以从syscall入口点查找内核堆栈。交换也交换缓存的gsbase段信息，而不是根据gs值本身从GDT重新加载。（wrgsbase可以独立于GDT / LDT更改GS基础）

AMD的设计是syscall不更改RSP以指向内核堆栈，并且不读取/写入任何内存，因此syscall它本身可以很快。但是随后您进入内核，其中所有寄存器都保存着它们的用户空间值。请参阅为什么Windows64使用与x86-64上所有其他操作系统不同的调用约定？在2000年左右内核开发人员和AMD架构师之间讨论邮件列表讨论的一些链接，在出售任何AMD64 CPU之前调整其设计syscall并swapgs使其可用。

---

显然，要跟踪GS当前是内核还是用户值对于错误处理是很棘手的：没有办法说“我现在要kernelgs”。您必须知道是否swapgs在任何错误处理路径中运行。唯一的指令是交换，而不是将其设置为一个与另一个。

阅读arch/x86/entry/entry_64.S例如https://github.com/torvalds/linux/blob/9fb71c2f230df44bdd237e9a4457849a3909017d/arch/x86/entry/entry_64.S#L1267（来自当前Linux）中的注释，其中提到了usergs，下一个注释块描述了swapgs在执行之前使用内核gsbase跳转到一些错误处理代码。

IIRC，Linux内核[gs:0]在该线程的内核堆栈的最低地址处拥有一个线程信息块。该块包括内核堆栈指针（作为绝对地址，而不是相对于gs）。

如果此错误基本上是在诱使内核rsp从用户控制的gsbase加载内核，或者搞砸了死胡同，swapgs从而使它gs在某些时候出现错误，我不会感到惊讶。