在Linux系统中,当涉及到用户态和内核态数据拷贝的时候,如果不考虑建立kernel space和user space的共享映射实现的零拷贝情况,一般是调用copy_from_user/copy_to_user/put_user/get_user几组宏来实现的。在早些时候,对于用户态指针非法(没有VMA)或者缺页(有VMA但是MMU没有映射)两种情况,在函数实现中使用修复表进行处理,前一种情况下会返回错误码,第二种情况则通过page fault流程建立物理PFN映射,之后在进入修复表流程完成剩下的操作。而对于合法的用户态指针,则直接在内核中访问即可。所以,从内核中可以直接访问当前进程的用户空间,所使用的虚拟地址也与当前进程处于用户空间时的地址完全相同。反之则不允许。
但是这个结论似乎在运行最新linux的 x86 平台上遇到了反例,即便在内核中访问合法的用户态地址,也会被禁止,做个实验:
在设备驱动中直接读取用户态传递下来的buf指针的内容:
运行用户态用例,发现测试进程被KILL,内核报告permission违例。
分析现场,发现出错地址0x7ffc922277b0和内核report的fault地址是一致的,并且,此虚拟地址对应的四级页表都有映射(PGD 23144d067 P4D 23144d067 PUD 2315d8067 PMD 23b0e9067 PTE, P4D和PGD重合)。也就是说,被访问的虚拟地址既不是非法地址,也不缺页,按照本文开头的分析,这个地址应该能够被内核安全访问才对,但是这里却报了错。
仔细分析出错LOG,发现出错原因是#PF: error_code(0x0001) - permissions violation,许可违例。
原因分析:
出现这个问题的原因和硬件架构和内核版本都有关系,最根本的原因是CPU硬引入了一个新的功能引起的,在最新的X86处理器的CR4寄存器中,引入了SMEP和SMAP 控制BIT,用来配置内核对用户态地址空间的访问权限。SMAP(Supervisor Mode Access Prevention)是Intel从Haswell微架构开始引入的一种新特征,它在CR4寄存器上引入一个新标志位SMAP,如果这个标志为1,内核访问用户进程的地址空间时就会触发一个页错误,目的是为了防止内核因为自身错误意外访问用户空间,这样就可以避免一些内核漏洞所导致的安全问题.但是由于内核在有些时候仍然需要访问用户空间,因此intel提供了两条指令STAC和CLAC用于临时打开/关闭这个功能,反复使用STAC和CLAC会带来一些轻微的性能损失,但考虑到增加的安全性,还是建议开启.
SMEP:位于Cr4的第20位,作用是让处于内核权限的CPU无法执行用户代码。
SMAP:位于Cr4的第21位,作用是让处于内核权限的CPU无法读写用户代码。
可以通过如下命令查看CPU是否支持smap功能,如下图所示,我的8核处理器每个核心都支持SMAP。
$ sudo cpuid|grep -i smap
而内核中有配置选项CONFIG_X86_SMAP用来启用或者关闭SMAP功能,默认情况下是打开的,所以才会遇到这个问题。
那么为什么copy_from_user/put_user宏又可以访问用户态指针呢?
以get_user为例,其它宏定义实现类似,在get_user的核心实现__get_user_1中,在进行真正的用户态指针访问前后,程序调用了ASM_STAC/ASM_CLAC去打开/关闭内核访问用户地址空间权限的功能:
并且在标号1处的修正表实现中也调用了CLAC指令对SMAP功能进行了控制,所以get_user才能安全地访问用户地址空间。
内核还提供了两个函数,用来供驱动开发者设置安全访问用户空间的代码区域,分别是#define user_access_begin和user_access_end。
用这两个调用保护访问用户内存的区域,重新测试:
发现程序正常执行,没有被KILL,说明这两个接口起到了作用。
作为对比,尝试关闭SMAP,重新编译内核,确认是否可以在内核中直接访问用户态地址:
测试发现,在关闭SMAP机制后,在内核模块中可以直接访问用户态的地址了:
总结:
所以,内核直接访问用户态指针导致报告page fault错误的原因是直接访问用户态内存触发了SMAP保护,内核提供了配置和API接口关闭这种保护,而本文开头提到的几个宏定义能够安全将访问用户态内存的原因,也是由于在访问器件,关闭了SMAP保护。
从普遍意义的角度来讲,内核态访问用户态地址空间是没有任何问题的,只是需要注意不同的架构下实现上会有微小差别,至少目前,没有看到其它架构有类似SMAP机制的实现。
参考文章
Supervisor Memory Protection - OSDev Wiki