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

papaofdoudou

已于 2024-03-10 16:05:03 修改

阅读量949

点赞数 4

CC 4.0 BY-SA版权

分类专栏：嵌入式系统 Linux 内存管理文章标签： linux 服务器

于 2023-10-28 20:15:21 首次发布

本文链接：https://blog.youkuaiyun.com/tugouxp/article/details/134093414

本文分析了在Linux系统中，由于SMAP（Supervisor Mode Access Prevention）机制导致的内核态无法直接访问合法用户态地址的问题。SMAP是Intel从Haswell微架构开始引入的，防止内核意外访问用户空间，增强安全性。当内核直接访问用户地址时，若开启SMAP，会触发Page Fault异常。通过`copy_from_user`等宏能安全访问用户空间是因为这些宏内部使用了STAC/CLAC指令暂时禁用SMAP。内核提供了`user_access_begin`和`user_access_end`接口供驱动安全访问用户空间。关闭SMAP或使用这些接口，内核可以正常访问用户态地址。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在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无法读写用户代码。