X86 SMAP(Supervisor Mode Access Prevention)机制引入的内核态访问用户态地址空间的问题分析

本文主要是介绍X86 SMAP(Supervisor Mode Access Prevention)机制引入的内核态访问用户态地址空间的问题分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在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违例。

仔细分析出错LOG，发现出错原因是#PF: error_code(0x0001) - permissions violation，许可违例。分析现场，发现出错地址0x7ffc922277b0和内核report的fault地址是一致的，并且，此虚拟地址对应的四级页表都有映射（PGD 23144d067 P4D 23144d067 PUD 2315d8067 PMD 23b0e9067 PTE, P4D和PGD重合)。也就是说，被访问的虚拟地址既不是非法地址，也没有缺页，是一个合法的用户态地址，按照本文开头的分析结论，此地址应该能够被内核安全访问才对，但是却报错了。

原因分析：

出现这个问题的原因和硬件架构和内核版本都有关系，最根本的原因是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

另一台12核AMD处理器SMAP支持情况

虚拟机系统不支持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才能安全地访问用户地址空间。

内核中clac/stac两条指令是以byte code形式定义的，我们可以DUMP kernel __get_user_1函数的实现，看其访存调用是否被stac/clac指令包围：

确信__get_user_1指令中的访存被stac/clac指令包围，这样就不需要触发permisson violation异常执行exception_table_entry中的修复代码了。

但观察运行内核对应的vmlinux文件反编译文件中的__get_user_1函数实现，发现其对应的stac/clac指令区域全部为NOP，推测可能是运行阶段程序会对NOP区域进行指令修改，将NOP替换为stac/clac指令。但是具体什么时候在哪里做的，暂不清楚。

直接调用CPU指令的方式不太优雅，内核提供了两个函数，分别是define user_access_begin和user_access_end，用来供驱动开发者设置安全访问用户空间的代码区域，本质是对两条指令的封装。

用这两个调用保护访问用户内存的区域，重新测试：

发现程序正常执行，没有被KILL，说明两个接口起到了作用，内核态顺利访问了用户态的地址空间。

作为对比，尝试关闭SMAP，重新编译内核，确认是否可以在内核中直接访问用户态地址：

测试发现，在关闭SMAP机制后，即便不调用stac/clac指令，在内核模块中也可以直接访问用户态的地址了：

另外稍微留意__get_user_1的实现会发现，它仅支持源地址为用户空间的访问申请，如果传入的源地址位于内核空间，将会直接跳转到bad_get_user标志出返回错误。这就是专业的API，内核态访问内核指针当然没问题，但是因为是get_user场景，那就应该有所为，有所不为，非不能也，实不为也。

流程分析

当关闭SMAP检查，执行标号1处的访存指令发生异常，触发do_page_fault后，系统会通过调用链do_page_fault->....->no_context->fixup_exception->search_exception_tables->handler...

执行ex_table中fixup字段指向的修复指令，1b对应的修复指令在.Lbad_get_user_clac，执行到这里首先会打开在访存前关闭的SMAP，之后返回错误码给应用。

为什么做的这么复杂呢？毕竟用户态的缺页处理对开发人员是透明的，系统能够保证即使缺页发生也能透明的向指定虚拟地址进行正确操作，为什么到了内核就不行了呢？必须要通过修复表显示修复。

个人的理解，如果仅仅是针对缺页的情况进行处理，内核page fault流程也可以做到提交物理页面后返回内核异常发生点继续处理。但是有一种情况比较特殊，内核无法参考用户态进程的处理方式，这种情况就是copy_to_user等宏接受到的地址是非法地址（没有在VMA区间），如果用户态发生这种情况，系统内核可以简单的发送一条KILL信号杀掉出问题的进程，但是copy_to_user是在内核态调用的，发生在内核态的非法地址异常的进程不能简单的通过发送KILL信号杀掉，因为系统不清楚在执行到异常点之前，内核代理的执行流是否有获取内核资源，比如锁，内存，信号等等，这个信息只有执行流本身清楚，所以，最好的办法是返回一个错误码，让执行流清理现场资源，并且带着错误码返回给用户态，让用户态决定是退出还是尝试继续系统调用。返回错误码的方式，就是将bad_get_user加入到 fixup修复表中，如下图：