linux内核：copy_to_user和copy_from_user

copy_to_user和copy_from_user

在linux内核中，我们将用户态数据拷贝到内核或者将用户态数据拷贝到内核，使用的是copy_from_user和copy_to_user。

但是在有些情况下，我们直接使用memcpy也不会出现错误，可以正常的将数据从内核态拷贝到用户态以及将数据从用户态拷贝到内核态，memcpy都不会发生错误。没发生错误是不是就不存在错误的情况呢？如果存在错误，那么什么时候使用memcpy会发生错误呢？memcpy和copy_{to/from}_user的区别又是什么呢？

32位arm架构

在32位架构上，将用户态数据拷贝到内核时，首先区分用户态数据的地址是否有效（也就是属于申请的虚拟地址范围）：

1、当用户态虚拟地址有效时，那么在内核中使用memcpy和copy_{to/from}_user的过程是一样的，不会出现任何问题。即使虚拟地址没有映射到物理内存，memcpy在内核态发生缺页后会由do_page_fault申请物理内存，然后建立虚拟地址和物理地址的映射，这个过程和copy_{to/from}_user一样。

2、当用户态虚拟地址无效时，内核态使用memcpy会导致缺页，然后调用do_page_fault申请物理内存。但是，由于虚拟地址是无效的，因此do_page_fault不能处理这种异常，也就不能建立虚拟地址和物理地址的映射关系，最终将导致kernel oops。

3、当用户态虚拟地址无效时，内核使用copy_{to/from}_user进行用户空间的数据拷贝，并且copy_{to/from}_user对所有内存操作的指令建立异常处理指令，也就是在对应的内存操作指令发生错误时，do_page_fault会跳转到异常处理处执行，处理后给用户空间返回错误提示，而不是直接报kernel oops。具体的过程如下：

copy_{to/from}_user操作用户态地址，此时虚拟地址无效（无效地址一定是没有和物理地址建立映射关系的），因此发生缺页异常。接着处理器进入do_page_fault发生异常的虚拟地址查找物理内存，此时发现虚拟地址无效，因此就会查找异常表（查找异常指令地址对应的异常处理地址），如果在异常处理表中查找到相应的处理项，就do_page_fault就返回到异常指令处理的地方执行，该异常处理指令最终给用户态返回一个错误，而不是kernel oops。

64位arm架构

在64位arm架构下，linux可以开启内核不能访问用户空间地址的选项，此时，我们内核就不能直接访问用户空间地址了，否则就会报错。既然不能访问用户空间地址，那在内核当中就不能使用memcpy来操作用户空间的数据，且只能使用copy_{to/from}_user。

这里有个疑问就是，copy_{to/from}_user操作的也是用户空间地址，为什么他们不会有问题，而memcpy会有问题呢？这就要从arm 64架构的特点说起了。

在arm64下，有两个页表：一个用户空间页表，一个内核空间页表。当我们开启了内核空间不能访问用户空间地址的选项时，进程在从用户空间切换到内核空间时，linux会将用户空间的页表设置为一个无效的页表。因此在kernel使用用户空间地址时，用户空间的页表是无效的，也就不能使用memcpy来交换用户空间和内核空间的数据了。而copy_{to/from}_user在交换用户空间和内核空间的数据时，会先将用户空间的页表设置回那个有效的页表，然后再执行数据的操作，所以

copy_{to/from}_user可以放问用户空间地址，而其他函数（例如memcpy）不能。

同样，copy_{to/from}_user对用户空间地址操作的指令都在异常处理表中建立了一个映射，当操作的用户空间地址异常时，发生缺页异常后do_page_fault不能建立虚拟地址和物理地址的映射管理，do_page_fault会查找异常指令对应的异常处理函数，然后跳转到异常处理指令处执行，最后给用户态空间返回一个错误，而不是kernel oops。