参考：http://www.wowotech.net/memory_management/454.html
宋大侠的文章精彩，郭大侠的评论也精彩。
结论简单摘录如下：
- 无论是内核态还是用户态访问合法的用户空间地址，当虚拟地址并未建立物理地址的映射关系的时候，page fault的流程几乎一样，都会帮助我们申请物理内存并创建映射关系。所以这种情况下memcpy()和copy_{to,from}_user()是类似的。
- 当内核态访问非法用户空间地址的时候，通过
.fixup和__ex_table两个段的帮助尝试修复异常。这种修复异常并不是建立地址映射关系，而是修改do_page_fault()返回地址。memcpy()由于没有创建这样的段，所以memcpy()无法做到这点。 - 在使能
CONFIG_ARM64_SW_TTBR0_PAN或者CONFIG_ARM64_PAN（硬件支持的情况下才有效）的时候，即使能禁止内核态访问用户态PGD，原理是通过修改TTBR0为一个全0的一级页表（和swap_page_dir一样，通过链接脚本分配占位）。此时我们只能使用copy_{to,from}_user()这种接口，直接使用memcpy()是不行的。 - 号外：用memory copy取代copy_{to,from}_user()是绝对禁止的，没有地址检查（access_ok）会引起安全问题。在4.13内核中有一个惨痛的案例：waitpid系统调用使用了unsafe版本的copy_to_user，遗漏了access_ok，从而导致了安全漏洞，而黑客可以利用该漏洞轻松的让普通进程获取root权限。
另外，当你想使用memory copy取代copy_{to,from}_user()的时候，你潜意识中做了一些假设。以32位系统为例，1G：3G的地址空间分配（高端1G内核空间在所有进程之间共享）并不是唯一的选择，也许4G:4G也未尝不可。假如系统配置是4G：4G，那么memory copy是无法取代copy_{to,from}_user()的。
其他链接：4G:4G：https://lwn.net/Articles/86715/ 及 https://lwn.net/Articles/39283/