copy_{to, from}_user()的思考

清逸之风

弁言

我们对copy_{to,from}_user()接心的利用该当是再熟习不外吧。根本Linux册本城市介绍它的感化。终究它是kernel space战user space相同的桥梁。一切的数据交互皆该当利用相似这类接心。以是，我们出有出处没有明白接心的感化。可是，我也已经有过以下疑问。

为何需求copy_{to,from}_user()，它终究正在背后为我们做了甚么？

copy_{to,from}_user()战memcpy()的区分是甚么，间接利用memcpy()能够吗？

memcpy()替换copy_{to,from}_user()是否是必然会有成绩？

一会儿找回了昔时猜疑的本人。我所提出的每一个成绩，已经我也考虑过。借没有行一次的考虑，每次皆有不同的设法。固然是由于从一开端便我便出有完整了解。如今又从头回到那个繁重的话题，持续考虑那已经的成绩。

温馨提醒：文章代码阐发基于Linux-4.18.0，部门架构相干代码以ARM64为代表。

万马齐喑

针对以上成绩固然是先百度。百度关于该成绩的专客也是许多，足以看出那个成绩必定猜疑着一多量Linux的喜好者。关于我的查阅成果来讲，概念次要分红以下两种：

copy_{to,from}_user()比memcpy()多了传上天址合理性校验。比方能否属于用户空间地点范畴。实际上道，内乱核空间能够间接利用用户空间传过去的指针，即便要做数据拷贝的行动，也能够间接利用memcpy()，究竟上正在出有MMU的系统架构上，copy_{to,from}_user()终极的完成便是利用了mencpy()。可是关于年夜大都有MMU的仄台，状况便有了些变革：用户空间传过去的指针是正在假造地点空间上的，它所指背的假造地点空间极可能借出有实正映照到实践的物理页里上。可是那又能如何呢？缺页招致的非常会很通明天被内乱核予以建复（为缺页的地点空间提交新的物理页里），会见到缺页的指令会持续运转似乎甚么皆出有发作一样。但那只是用户空间缺页非常的举动，正在内乱核空间这类缺页非常必需被隐式天建复，那是由内乱核供给的缺页非常处置函数的设想形式决议的。其背后的思惟是：正在内乱核态，假如法式试图会见一个还没有被提交物理页里的用户空间地点，内乱核必需对此连结借鉴而不克不及像用户空间那样毫无发觉。
假如我们确保用户态通报的指针的准确性，我们完整能够用memcpy()函数替换copy_{to,from}_user()。经过一些实验测试，发明利用memcpy()，法式的运转上并出有成绩。因而正在确保用户态指针宁静的状况下，两者能够交换。

从各家专客上，概念次要集合正在第一面。看起去第一面遭到大家的普遍承认。可是，重视理论的人又得出了第两种概念，终究是理论出实知。真谛终究是是把握正在少数人脚里呢？仍是大众的眼睛是雪明的呢？固然，我没有否认以上任何一种概念。也不克不及背您保证哪一种概念准确。由于，我信赖即便是已经自作掩饰的实际，跟着工夫的推移大概特定状况的改动实际也能够没有再准确。比如，牛顿的典范力教实际（仿佛扯得有面近）。假如要我道人话，便是：跟着工夫的推移，Linux的代码正在不竭的变革。大概以上的概念正在已经准确。固然，也能够如今借准确。上面的阐发便是我的概念了。一样，大家也是需求连结疑心的立场。上面我便举一反三。
举一反三

起首我们看下memcpy()战copy_{to,from}_user()的函数界说。参数险些出有不同，皆包含目标地点，源地点战需求复造的字节size。

static __always_inline unsigned long __must_check
copy_to_user(void __user *to, const void *from, unsigned long n);
static __always_inline unsigned long __must_check
copy_from_user(void *to, const void __user *from, unsigned long n);
void *memcpy(void *dest, const void *src, size_t len);

复造代码

可是，有一面我们必定是明白的。那便是memcpy()出有传上天址合理性校验。而copy_{to,from}_user()针对传上天址举办相似上面的合理性校验（简朴道面，更多校验详情能够参考代码）。

假如从用户空间copy数据到内乱核空间，用户空间地点to及to减上copy的字节少度n必需位于用户空间地点空间。
假如从内乱核空间copy数据到用户空间，固然也需求查抄地点的合理性。比方，能否越界会见大概是否是代码段的数据等等。总之统统没有合理天操纵皆需求立刻根绝。

经过简朴的比照以后，我们再看看其他的差别和一同讨论下上里提出的2个概念。我们先从第2个概念提及。触及理论，我仍是有面信赖理论出实知。从我测试的成果来讲，完成成果分红两种状况。
第一种状况的成果是：利用memcpy()测试，出有呈现成绩，代码一般运转。测试代码以下（仅仅展现proc文件体系下file_operations对应的read接心函数）：

static ssize_t test_read(struct file *file, char __user *buf,
size_t len, loff_t *offset)
{
memcpy(buf, "test\n", 5); /* copy_to_user(buf, "test\n", 5) */
return 5;
}

复造代码

我们利用cat号令读与文件内乱容，cat会经由过程体系挪用read挪用test_read，并且通报的buf巨细是4k。测试很顺遂，成果很喜人。胜利天读到了“test”字符串。看起去，第2面概念是出短处的。可是，我们借需求持续考证战探求下来。由于第1个概念提到，“正在内乱核空间这类缺页非常必需被隐式天建复”。因而我们借需求考证的状况是：假如buf正在用户空间曾经分派假造地点空间，可是并出有创立战物理内乱存的详细映照干系，这类状况下会呈现内乱核态page fault。我们起首需求创立这类前提，找到契合的buf，然后测试。那里我固然出测啦。由于有测试结论（次要是由于我懒，机关那个前提我以为比力费事）。那个测试是我的一个伴侣，人称宋教师的“阿助教”阿克曼年夜牛。他已经做个那个尝试，并且获得的结论是：即便是出有创立战物理内乱存的详细映照干系的buf，代码也能够一般运转。正在内乱核态发作page fault，并被其建复（分派详细物理内乱存，添补页表，创立映照干系）。同时，我从代码的角度阐发，结论也是云云。
经过上里的阐发，看起去仿佛是memcpy()也能够一般利用，鉴于宁静天思索倡议利用copy_{to,from}_user()等接心。
第两种状况的成果是：以上的测试代码并出有一般运转，并且会触收kernel oops。固然本次测试战前次测试的kernel设置选项是纷歧样的。那个设置项是 CONFIG_ARM64_SW_TTBR0_PAN大概 CONFIG_ARM64_PAN（针对ARM64仄台）。两个设置选项的功用皆是阻遏内乱核态间接会见用户地点空间。只不外CONFIG_ARM64_SW_TTBR0_PAN是硬件仿实在现这类功用，而CONFIG_ARM64_PAN是硬件完成功用（ARMv8.1扩大功用）。我们以CONFIG_ARM64_SW_TTBR0_PAN做为阐发工具（硬件仿实才有代码供给阐发）。BTW，假如硬件没有撑持，即便设置CONFIG_ARM64_PAN也出用，只能利用硬件仿实的办法。假如需求会见用户空间地点需求经由过程相似copy_{to,from}_user()的接心，不然会招致kernel oops。
正在翻开CONFIG_ARM64_SW_TTBR0_PAN的选项后，测试以上代码便会招致kernel oops。缘故原由便是内乱核态间接会见了用户空间地点。因而，正在这类状况我们便不成以利用memcpy()。我们别无挑选，只能利用copy_{to,from}_user()。
为何我们需求PAN（Privileged Access Never）功用呢？缘故原由多是用户空间战内乱核空间数据交互上简单引进宁静成绩，以是我们便没有让内乱核空间随便会见用户空间，假如非要那么做，便必需经由过程特定的接心封闭PAN。另外一圆里，PAN功用能够愈加标准化内乱核态战用户态数据交互的接心利用。正在使能PAN功用的状况下，能够迫使内乱核大概驱动开拓者利用copy_{to,from}_user()等宁静接心，提拔体系的宁静性。相似memcpy()非标准操纵，kernel便oops给您看。
因为编程的没有标准而引进宁静缺点。比方：Linux内乱核缺点CVE-2017-5123能够提拔权限。该缺点的引进缘故原由便是是短少access_ok()查抄用户通报地点的合理性。因而，为了不本人编写的代码引进宁静成绩，针对内乱核空间战用户空间数据交互上，我们要非分特别留神。
寻根究底

既然提到了CONFIG_ARM64_SW_TTBR0_PAN的设置选项。固然我也期望理解其背后设想的道理。因为ARM64的硬件特别设想，我们利用两个页表基地点存放器ttbr0_el1战ttbr1_el1。处置器按照64 bit地点的下16 bit判定会见的地点属于用户空间仍是内乱核空间。假如是用户空间地点则利用ttbr0_el1，反之利用ttbr1_el1。因而，ARM64历程切换的时分，只需求改动ttbr0_el1的值便可。ttbr1_el1能够挑选没有需求改动，由于一切的历程同享不异的内乱核空间地点。
当历程切换到内乱核态（中止，非常，体系挪用等）后，怎样才华制止内乱核态会见用户态地点空间呢？实在没有易念出，改动ttbr0_el1的值便可，指背一段不法的映照便可。因而，我们为此筹办了一份特别的页表，该页表巨细4k内乱存，其值满是0。当历程切换到内乱核态后，修正ttbr0_el1的值为该页表的地点便可保证会见用户空间地点长短法会见。由于页表的值长短法的。那个特别的页表内乱存经由过程链接剧本分派。

#define RESERVED_TTBR0_SIZE (PAGE_SIZE)
SECTIONS
{
reserved_ttbr0 = .;
. += RESERVED_TTBR0_SIZE;
swapper_pg_dir = .;
. += SWAPPER_DIR_SIZE;
swapper_pg_end = .;
}

复造代码

那个特别的页表战内乱核页表正在一同。战swapper_pg_dir仅仅好4k巨细。reserved_ttbr0地点开端的4k内乱存空间的内乱容会被浑整。
当我们进进内乱核态后会经由过程__uaccess_ttbr0_disable切换ttbr0_el1以封闭用户空间地点会见，正在需求会见的时分经由过程_uaccess_ttbr0_enable翻开用户空间地点会见。那两个宏界说也没有庞大，便以_uaccess_ttbr0_disable为例阐明道理。其界说以下：

.macro __uaccess_ttbr0_disable, tmp1
mrs \tmp1, ttbr1_el1 // swapper_pg_dir (1)
bic \tmp1, \tmp1, #TTBR_ASID_MASK
sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before
// swapper_pg_dir (2)
msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1 (3)
isb
add \tmp1, \tmp1, #RESERVED_TTBR0_SIZE
msr ttbr1_el1, \tmp1 // set reserved ASID
isb
.endm

复造代码

ttbr1_el1存储的是内乱核页表基地点，因而其值便是swapper_pg_dir。

swapper_pg_dir加来RESERVED_TTBR0_SIZE便是上里形貌的特别页表。

将ttbr0_el1修正指背那个特别的页表基地点，固然能够保证后绝会见用户地点皆长短法的。

__uaccess_ttbr0_disable对应的C言语完成能够参考那里。怎样许可内乱核态会见用户空间地点呢？也很简朴，便是__uaccess_ttbr0_disable的反操纵，给ttbr0_el1付与合理的页表基地点。那里便没必要反复了。我们如今需求明白的究竟便是，正在设置CONFIG_ARM64_SW_TTBR0_PAN的状况下，copy_{to,from}_user()接心会正在copy之前许可内乱核态会见用户空间，并正在copy完毕以后封闭内乱核态会见用户空间的才能。因而，利用copy_{to,from}_user()才是正统做法。次要表现正在宁静性查抄及宁静会见处置。那里是其比memcpy()多的第一个特征，前面借会介绍另外一个主要特征。
如今我们能够解问上一节中遗留的成绩。如何才华持续利用memcpy()？如今便很简朴了，正在memcpy()挪用之前经由过程uaccess_enable_not_uao()许可内乱核态会见用户空间地点，挪用memcpy()，最初经由过程uaccess_disable_not_uao()封闭内乱核态会见用户空间的才能。
有备无患

以上的测试用例皆是创立正在用户空间通报合理地点的根柢上测试的，何为合理的用户空间地点？用户空间经由过程体系挪用申请的假造地点空间包含的地点范畴，即是合理的地点（不管能否分派物理页里创立映照干系）。既然要写一个接心法式，固然也要思索法式的坚固性，我们不克不及假定一切的用户通报的参数皆是合理的。我们该当预判不法传参状况的发作，并提早做好筹办，那便是有备无患。
我们起首利用memcpy()的测试用例，随机通报一个不法的地点。经过测试发明：会触收kernel oops。持续利用copy_{to,from}_user()替换memcpy()测试。测试发明：read()仅仅是返回毛病，但没有会触收kernel oops。那才是我们念要的成果。终究，一个使用法式不该该触收kernel oops。这类机造的完成道理是甚么呢？
我们以copy_to_user()为例阐发。函数挪用流程是：

copy_to_user()->_copy_to_user()->raw_copy_to_user()->__arch_copy_to_user()

复造代码

_arch_copy_to_user()正在ARM64仄台是汇编代码完成，那部门代码很枢纽。

end .req x5
ENTRY(__arch_copy_to_user)
uaccess_enable_not_uao x3, x4, x5
add end, x0, x2
#include "copy_template.S"
uaccess_disable_not_uao x3, x4
mov x0, #0
ret
ENDPROC(__arch_copy_to_user)
.section .fixup,"ax"
.align 2
9998: sub x0, end, dst // bytes not copied
ret
.previous

复造代码

uaccess_enable_not_uao战uaccess_disable_not_uao是上里道到的内乱核态会见用户空间的开闭。

copy_template.S文件是汇编完成的memcpy()的功用，稍后看看memcpy()的完成代码便分明了。

.section.fixup,“ax”界说一个section，名为“.fixup”，权限是ax（‘a’可重定位的段，‘x’可施行段）。 9998标号处的指令便是“有备无患”的擅后处置事情。借记得copy_{to,from}_user()返回值的意义吗？返回0代表copy胜利，不然返回盈余出有copy的字节数。那止代码便是计较盈余出有copy的字节数。当我们会见不法的用户空间地点的时分，便必然会触收page fault。这类状况下，内乱核态发作的page fault并返回的时分并出有建复非常，以是必定不克不及返回发作非常的地点持续运转。以是，体系能够有2个挑选：第1个挑选是kernel oops，并给当行进程收收SIGSEGV旌旗灯号；第2个挑选是没有返回呈现非常的地点运转，而是挑选一个曾经建复的地点返回。假如利用的是memcpy()便只要第1个挑选。可是copy_{to,from}_user()能够有第2个挑选。 .fixup段便是为了完成那个建复功用。当copy过程当中呈现会见不法用户空间地点的时分，do_page_fault()返回的地点酿成 9998标号处，此时能够计较盈余已copy的字节少度，法式借能够持续施行。

比照前里阐发的成果，实在_arch_copy_to_user()能够远似等效以下干系。

uaccess_enable_not_uao();
memcpy(ubuf, kbuf, size); == __arch_copy_to_user(ubuf, kbuf, size);
uaccess_disable_not_uao();

复造代码

先插播一条动静，注释copy_template.S为什么是memcpy()。memcpy()正在ARM64仄台是由汇编代码完成。其界说正在arch/arm64/lib/memcpy.S文件。

.weak memcpy
ENTRY(__memcpy)
ENTRY(memcpy)
#include "copy_template.S"
ret
ENDPIPROC(memcpy)
ENDPROC(__memcpy)

复造代码

以是很较着，memcpy()战__memcpy()函数界说是一样的。并且memcpy()函数声明是weak，因而能够重写memcpy()函数（扯得有面近）。再扯一面，为什么利用汇编呢？为什么没有利用lib/string.c文件的memcpy()函数呢？固然是为了劣化memcpy() 的施行速率。lib/string.c文件的memcpy()函数是根据字节为单元举办copy（再好的硬件也会被粗拙的代码誉失落）。可是如今的处置器根本皆是32大概64位，完整能够4 bytes大概8 bytes以至16 bytes copy（思索地点对齐的状况下）。能够较着提拔施行速率。以是，ARM64仄台利用汇编完成。那部门常识能够参考那篇专客《ARM64 的 memcpy 劣化取完成》。
上面持续进进正题，再反复一遍：内乱核态会见用户空间地点，假如触收page fault，只需用户空间地点合理，内乱核态也会像甚么也出有发作一样建复非常（分派物理内乱存，创立页表映照干系）。可是假如会见不法用户空间地点，便挑选第2条路，尝试救赎本人。那条路便是利用 .fixup战 __ex_table段。假如有力回天只能给当行进程收收SIGSEGV旌旗灯号。并且，沉则kernel oops，重则panic（与决于kernel设置选项CONFIG_PANIC_ON_OOPS）。正在内乱核态会见不法用户空间地点的状况下，do_page_fault()终极会跳转 no_context标号处的do_kernel_fault()。

static void __do_kernel_fault(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
/*
* Are we prepared to handle this kernel fault?
* We are almost certainly not prepared to handle instruction faults.
*/
if (!is_el1_instruction_abort(esr) && fixup_exception(regs))
return;
/* ... */
}

复造代码

fixup_exception()持续挪用search_exception_tables()，其经由过程查找_extable段。__extable段存储exception table，每一个entry存储着非常地点及其对应建复的地点。比方上述的 9998:subx0,end,dst指令的地点便会被找到并修正do_page_fault()函数的返回地点，以到达跳转建复的功用。实在查找历程是按照出成绩的地点addr，查找_extable段（exception table）能否有对应的exception table entry，假如有便代表能够被建复。因为32位处置器战64位处置器完成方法有不同，因而我们先从32位处置器非常表的完成道理提及。
_extable段的尾尾地点别离是 __start___ex_table战 __stop___ex_table（界说正在include/asm-generic/vmlinux.lds.h。那段内乱存能够看做是一个数组，数组的每一个元素皆是 struct exception_table_entry范例，其纪录着非常发作地点及其对应的建复地点。

exception tables
__start___ex_table --> +---------------+
| entry |
+---------------+
| entry |
+---------------+
| ... |
+---------------+
| entry |
+---------------+
| entry |
__stop___ex_table --> +---------------+

复造代码

正在32位处置器上，struct exception_table_entry界说以下：

struct exception_table_entry {
unsigned long insn, fixup;
};

复造代码

有一面需求明白，正在32位处置器上，unsigned long是4 bytes。insn战fixup别离存储非常发作地点及其对应的建复地点。按照非常地点ex_addr查找对应的建复地点（已找到返回0），其表示代码以下：

unsigned long search_fixup_addr32(unsigned long ex_addr)
{
const struct exception_table_entry *e;
for (e = __start___ex_table; e < __stop___ex_table; e++)
if (ex_addr == e->insn)
return e->fixup;
return 0;
}

复造代码

正在32位处置器上，创立exception table entry相对简朴。针对copy{to,from}user()汇编代码中每处用户空间地点会见的指令城市创立一个entry，并且insn存储当前指令对应的地点，fixup存储建复指令对应的地点。
当64位处置器开端开展起去，假如我们持续利用这类方法，必将需求2倍于32位处置器的内乱存存储exception table（由于存储一个地点需求8 bytes）。以是，kernel换用另外一种方法完成。正在64处置器上，struct exception_table_entry界说以下：

struct exception_table_entry {
int insn, fixup;
};

复造代码

每一个exception table entry占用的内乱存战32位处置器状况一样，因而内乱存占用稳定。可是insn战fixup的意义发作变革。insn战fixup别离存储着非常发作地点及建复地点相对当前构造体成员地点的偏偏移（有面拗心）。比方，按照非常地点ex_addr查找对应的建复地点（已找到返回0），其表示代码以下：

unsigned long search_fixup_addr64(unsigned long ex_addr)
{
const struct exception_table_entry *e;
for (e = __start___ex_table; e < __stop___ex_table; e++)
if (ex_addr == (unsigned long)&e->insn + e->insn)
return (unsigned long)&e->fixup + e->fixup;
return 0;
}

复造代码

因而，我们的存眷面便是怎样来构建exception_table_entry。我们针对每一个用户空间地点的内乱存会见皆需求创立一个exception table entry，并插进_extable段。比方上面的汇编指令（汇编指令对应的地点是随便写的，不用纠结对错。了解道理才是霸道）。

0xffff000000000000: ldr x1, [x0]
0xffff000000000004: add x1, x1, #0x10
0xffff000000000008: ldr x2, [x0, #0x10]
/* ... */
0xffff000040000000: mov x0, #0xfffffffffffffff2 // -14
0xffff000040000004: ret

复造代码

假定x0存放器保存着用户空间地点，因而我们需求对0xffff000000000000地点的汇编指令创立一个exception table entry，并且我们希冀当x0长短法用户空间地点时，跳转返回的建复地点是0xffff000040000000。为了计较简朴，假定那是创立第一个entry， __start___ex_table值是0xffff000080000000。那末第一个exception table entry的insn战fixup成员的值别离是：0x80000000战0xbffffffc（那两个值皆是背数）。因而，针对copy{to,from}user()汇编代码中每处用户空间地点会见的指令城市创立一个entry。以是0xffff000000000008地点处的汇编指令也需求创立一个exception table entry。
以是，假如内乱核态会见不法用户空间地点终究发作了甚么？上里的阐发流程能够总结以下：

会见不法用户空间地点：
0xffff000000000000:ldr x1,[x0]
MMU触收非常
CPU挪用do_page_fault()
do_page_fault()挪用search_exception_table()（regs->pc == 0xffff000000000000）
检察_extable段，寻觅0xffff000000000000 并且返回建复地点0xffff000040000000
do_page_fault()修正函数返回地点（regs->pc = 0xffff000040000000）并返回
法式持续施行，处置出错状况
修正函数返回值x0 = -EFAULT (-14) 并返回（ARM64经由过程x0通报函数返回值）

总结

到了回忆总结的时分，copy_{to,from}_user()的考虑也到此完毕。我们去个总结完毕此文。

不管是内乱核态仍是用户态会见合理的用户空间地点，当假造地点并已创立物理地点的映照干系的时分，page fault的流程险些一样，城市赞助我们申请物理内乱存并创立映照干系。以是这类状况下memcpy()战copy_{to,from}_user()是相似的。
当内乱核态会见不法用户空间地点的时分，按照非常地点查找建复地点。这类建复非常的办法并非创立地点映照干系，而是修正do_page_fault()返回地点。而memcpy()没法做到那面。
正在使能 CONFIG_ARM64_SW_TTBR0_PAN大概 CONFIG_ARM64_PAN（硬件撑持的状况下才有用）的时分，我们只能利用copy_{to,from}_user()这类接心，间接利用memcpy()是不可的。

最初，我念道，即便正在某些状况下memcpy()能够一般事情。可是，那也是没有保举的，没有是优良的编程风俗。正在用户空间战内乱核空间数据交互上，我们必需利用相似copy_{to,from}_user()的接心。为何相似呢？由于还有其他的接心用于内乱核空间战用户空间数据交互，只是出有copy_{to,from}_user()驰名。比方：{get,put}_user()。
本文转载自蜗窝科技:
http://www.wowotech.net/memory_management/454.html

（完）
更多出色，尽正在"Linux阅码场"，扫描下圆两维码存眷

感激您的耐烦浏览，请顺手转收一下大概面个“正在看”吧~

免责声明：假如进犯了您的权益，请联络站少，我们会实时删除侵权内乱容，感谢协作！

copy_{to, from}_user()的思考

浏览过的版块