关于Linux内核提交中usergs相关语句的技术问询（关联CVE-2018-8897）

咱们把这句话拆成两部分，结合你已经熟悉的内核知识来拆解，就很容易理解了：

第一部分："我们不允许kprobes在内核模式下处于usergs的位置运行" #

这里的usergs指的是用户态GS段选择子——内核运行时默认使用专属的内核GS段（用来访问per-CPU的内核数据），而用户态程序有自己独立的GS段。kprobes作为内核的动态插桩机制，它的运行上下文完全是纯内核态：不管是触发kprobe的代码路径，还是kprobe自身的处理逻辑，都在内核特权级下执行，并且全程使用内核GS段，从设计上就不可能切换到用户态的GS段环境中。

简单说：kprobes天生就碰不到usergs对应的内核模式场景，它的运行环境和用户态GS段完全绝缘。

第二部分："因此‘paranoid’也没有必要" #

这里的paranoid指的是之前代码里为了防范kprobes在usergs环境下运行可能引发的风险（比如和CVE-2018-8897这类指令异常处理漏洞的交互）而添加的冗余安全检查。既然已经明确kprobes根本不会处于usergs的内核模式环境中，那这些为极端场景准备的防御性代码就完全失去了存在的意义——留着只会增加代码复杂度，还可能带来不必要的性能开销。

结合CVE-2018-8897的背景来看，这个提交是在修复漏洞的同时做的代码清理：漏洞本身是内核误处理POP/MOV SS后的#DB异常，但kprobes的运行场景根本碰不到触发该漏洞的usergs环境，所以对应的paranoid检查可以放心移除。

内容的提问来源于stack exchange，提问作者Arthur Dent