这是参考CVE-2018-8897(与CVE-2018-1087相关),描述如下:
Intel 64和IA-32架构软件开发人员手册(SDM)的系统编程指南中的一些声明在部分或全部操作系统内核的开发中处理不当,导致#DB的意外行为由MOV SS或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.3节) 。如果MOV到SS或POP到SS指令之后的指令是SYSCALL,SYSENTER,INT 3等指令,它们在CPL<操作系统上将控制权转移到操作系统。如图3所示,在转移到CPL之后传送调试异常< 3完成了。操作系统内核可能不会期望这种事件顺序,因此可能会在发生事件时遇到意外行为。
在阅读this related git commit to the Linux kernel时,我注意到提交消息指出:
x86 / entry / 64:不要在#BP堆栈中使用IST条目
对于#BP / int3来说,没有什么值得的。我们不允许kprobes 在内核中少数几个在CPL0上运行的地方 无效的堆栈,32位内核使用了正常的中断 #BP永远的大门。
此外,我们不允许在有用户名的地方使用kprobes 在内核模式中,所以"偏执"也没必要。
鉴于漏洞,我试图理解提交消息中的最后一句/段落。我知道IST条目是指(据称)已知的商品之一"中断堆栈表中的堆栈指针,可用于处理中断。我也理解#BP是指一个断点异常(相当于INT3
),并且kprobes是声称只在内核的第0环(CPL0
)运行的调试机制。 )特权级别。
但我完全迷失在下一部分,这可能是因为" usergs"是一个错字,我只是错过了预期的目的:
此外,我们不允许在有用户名的地方使用kprobes 在内核模式中,所以"偏执"也没必要。
这句话是什么意思?