5. 内核级异常处理¶
Joerg Pommnitz <joerg@raleigh.ibm.com> 的评论
当进程在内核模式下运行时，它经常需要访问用户模式内存，该内存的地址由不受信任的程序传递。 为了保护自己，内核必须验证此地址。
在旧版本的 Linux 中，这是通过 int verify_area(int type, const void * addr, unsigned long size) 函数完成的（该函数此后已被 access_ok() 替换）。
此函数验证了从地址“addr”开始，大小为“size”的内存区域是否可用于类型中指定的操作（读取或写入）。 为此，verify_read 必须查找包含地址 addr 的虚拟内存区域 (vma)。 在正常情况下（正确工作的程序），此测试成功。 它仅对一些有错误的程序失败。 在某些内核分析测试中，这种通常不需要的验证占用了相当多的时间。
为了克服这种情况，Linus 决定让每个支持 Linux 的 CPU 中存在的虚拟内存硬件处理此测试。
这是如何工作的？
每当内核尝试访问当前无法访问的地址时，CPU 都会生成页面错误异常并调用页面错误处理程序
void exc_page_fault(struct pt_regs *regs, unsigned long error_code)
在 arch/x86/mm/fault.c 中。 堆栈上的参数由 arch/x86/entry/entry_32.S 中的低级汇编粘合代码设置。 参数 regs 是指向堆栈上保存的寄存器的指针，error_code 包含异常的原因代码。
exc_page_fault() 首先从 CPU 控制寄存器 CR2 获取无法访问的地址。 如果该地址位于进程的虚拟地址空间内，则可能发生故障，因为该页未被交换，写保护或类似情况。 但是，我们对另一种情况感兴趣：该地址无效，没有包含该地址的 vma。 在这种情况下，内核跳转到 bad_area 标签。
在那里，它使用导致异常的指令的地址（即 regs->eip）来查找可以继续执行的地址 (fixup)。 如果此搜索成功，则故障处理程序会修改返回地址（再次 regs->eip）并返回。 执行将在 fixup 中的地址处继续。
fixup 指向哪里？
由于我们跳转到 fixup 的内容，因此 fixup 显然指向可执行代码。 此代码隐藏在用户访问宏中。 我选择了在 arch/x86/include/asm/uaccess.h 中定义的 get_user() 宏作为示例。 定义有点难以理解，所以让我们看看预处理器和编译器生成的代码。 我选择了 drivers/char/sysrq.c 中的 get_user() 调用进行详细检查。
sysrq.c 第 587 行中的原始代码
get_user(c, buf);
预处理器输出（已编辑为可读）
(
{
long __gu_err = - 14 , __gu_val = 0;
const __typeof__(*( ( buf ) )) *__gu_addr = ((buf));
if (((((0 + current_set[0])->tss.segment) == 0x18 ) ||
(((sizeof(*(buf))) <= 0xC0000000UL) &&
((unsigned long)(__gu_addr ) <= 0xC0000000UL - (sizeof(*(buf)))))))
do {
__gu_err = 0;
switch ((sizeof(*(buf)))) {
case 1:
__asm__ __volatile__(
"1: mov" "b" " %2,%" "b" "1\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %3,%0\n"
" xor" "b" " %" "b" "1,%" "b" "1\n"
" jmp 2b\n"
".section __ex_table,\"a\"\n"
" .align 4\n"
" .long 1b,3b\n"
".text" : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *)
( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err )) ;
break;
case 2:
__asm__ __volatile__(
"1: mov" "w" " %2,%" "w" "1\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %3,%0\n"
" xor" "w" " %" "w" "1,%" "w" "1\n"
" jmp 2b\n"
".section __ex_table,\"a\"\n"
" .align 4\n"
" .long 1b,3b\n"
".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err ));
break;
case 4:
__asm__ __volatile__(
"1: mov" "l" " %2,%" "" "1\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %3,%0\n"
" xor" "l" " %" "" "1,%" "" "1\n"
" jmp 2b\n"
".section __ex_table,\"a\"\n"
" .align 4\n" " .long 1b,3b\n"
".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
( __gu_addr )) ), "i"(- 14 ), "0"(__gu_err));
break;
default:
(__gu_val) = __get_user_bad();
}
} while (0) ;
((c)) = (__typeof__(*((buf))))__gu_val;
__gu_err;
}
);
哇！ 黑色GCC/汇编魔法。 这不可能理解，所以让我们看看 gcc 生成什么代码
> xorl %edx,%edx
> movl current_set,%eax
> cmpl $24,788(%eax)
> je .L1424
> cmpl $-1073741825,64(%esp)
> ja .L1423
> .L1424:
> movl %edx,%eax
> movl 64(%esp),%ebx
> #APP
> 1: movb (%ebx),%dl /* this is the actual user access */
> 2:
> .section .fixup,"ax"
> 3: movl $-14,%eax
> xorb %dl,%dl
> jmp 2b
> .section __ex_table,"a"
> .align 4
> .long 1b,3b
> .text
> #NO_APP
> .L1423:
> movzbl %dl,%esi
优化器做得很好，给了我们一些我们可以理解的东西。 我们可以吗？ 实际的用户访问非常明显。 由于统一的地址空间，我们可以直接访问用户内存中的地址。 但是 .section stuff 做什么?????
要理解这一点，我们必须查看最终内核
> objdump --section-headers vmlinux
>
> vmlinux: file format elf32-i386
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 00098f40 c0100000 c0100000 00001000 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 1 .fixup 000016bc c0198f40 c0198f40 00099f40 2**0
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 2 .rodata 0000f127 c019a5fc c019a5fc 0009b5fc 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 __ex_table 000015c0 c01a9724 c01a9724 000aa724 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .data 0000ea58 c01abcf0 c01abcf0 000abcf0 2**4
> CONTENTS, ALLOC, LOAD, DATA
> 5 .bss 00018e21 c01ba748 c01ba748 000ba748 2**2
> ALLOC
> 6 .comment 00000ec4 00000000 00000000 000ba748 2**0
> CONTENTS, READONLY
> 7 .note 00001068 00000ec4 00000ec4 000bb60c 2**0
> CONTENTS, READONLY
在生成的对象文件中显然有 2 个非标准 ELF 节。 但首先，我们想知道我们的代码在最终内核可执行文件中发生了什么
> objdump --disassemble --section=.text vmlinux
>
> c017e785 <do_con_write+c1> xorl %edx,%edx
> c017e787 <do_con_write+c3> movl 0xc01c7bec,%eax
> c017e78c <do_con_write+c8> cmpl $0x18,0x314(%eax)
> c017e793 <do_con_write+cf> je c017e79f <do_con_write+db>
> c017e795 <do_con_write+d1> cmpl $0xbfffffff,0x40(%esp,1)
> c017e79d <do_con_write+d9> ja c017e7a7 <do_con_write+e3>
> c017e79f <do_con_write+db> movl %edx,%eax
> c017e7a1 <do_con_write+dd> movl 0x40(%esp,1),%ebx
> c017e7a5 <do_con_write+e1> movb (%ebx),%dl
> c017e7a7 <do_con_write+e3> movzbl %dl,%esi
整个用户内存访问减少到 10 条 x86 机器指令。 .section 指令中包含的指令不再位于正常的执行路径中。 它们位于可执行文件的不同部分
> objdump --disassemble --section=.fixup vmlinux
>
> c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
> c0199ffa <.fixup+10ba> xorb %dl,%dl
> c0199ffc <.fixup+10bc> jmp c017e7a7 <do_con_write+e3>
最后
> objdump --full-contents --section=__ex_table vmlinux
>
> c01aa7c4 93c017c0 e09f19c0 97c017c0 99c017c0 ................
> c01aa7d4 f6c217c0 e99f19c0 a5e717c0 f59f19c0 ................
> c01aa7e4 080a18c0 01a019c0 0a0a18c0 04a019c0 ................
或以人类可读的字节顺序
> c01aa7c4 c017c093 c0199fe0 c017c097 c017c099 ................
> c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
^^^^^^^^^^^^^^^^^
this is the interesting part!
> c01aa7e4 c0180a08 c019a001 c0180a0a c019a004 ................
发生了什么？ 汇编指令
.section .fixup,"ax"
.section __ex_table,"a"
告诉汇编器将以下代码移动到 ELF 对象文件中的指定节。 所以这些指令
3: movl $-14,%eax
xorb %dl,%dl
jmp 2b
最终位于对象文件的 .fixup 节中，并且地址
.long 1b,3b
最终位于对象文件的 __ex_table 节中。 1b 和 3b 是本地标签。 本地标签 1b（1b 代表下一个标签 1 向后）是可能发生故障的指令的地址，即在本例中，标签 1 的地址是 c017e7a5：原始汇编代码：> 1: movb (%ebx),%dl 并且链接在 vmlinux 中：> c017e7a5 <do_con_write+e1> movb (%ebx),%dl
本地标签 3（再次向后）是处理故障的代码的地址，在本例中，实际值是 c0199ff5：原始汇编代码：> 3: movl $-14,%eax 并且链接在 vmlinux 中：> c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
如果 fixup 能够处理异常，则控制流可能会返回到触发故障的指令之后的指令，即本地标签 2b。
汇编代码
> .section __ex_table,"a"
> .align 4
> .long 1b,3b
变为值对
> c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
^this is ^this is
1b 3b
内核异常表中的 c017e7a5,c0199ff5。
那么，如果来自内核模式的故障没有合适的 vma 会发生什么？
访问无效地址
> c017e7a5 <do_con_write+e1> movb (%ebx),%dl
MMU 生成异常
CPU 调用 exc_page_fault()
exc_page_fault() 调用 do_user_addr_fault()
do_user_addr_fault() 调用 kernelmode_fixup_or_oops()
kernelmode_fixup_or_oops() 调用 fixup_exception() (regs->eip == c017e7a5);
fixup_exception() 调用 search_exception_tables()
search_exception_tables() 在异常表（即 ELF 节 __ex_table 的内容）中查找地址 c017e7a5，并返回关联的故障处理代码 c0199ff5 的地址。
fixup_exception() 修改其自己的返回地址以指向故障处理代码并返回。
执行在故障处理代码中继续。
EAX 变为 -EFAULT (== -14)
DL 变为零（我们从用户空间“读取”的值）
执行在本地标签 2（紧接在发生故障的用户访问之后的指令的地址）处继续。
上面的步骤 a 到 c 在某种程度上模拟了发生故障的指令。
这就是全部，大部分。 如果您查看我们的示例，您可能会问为什么我们在异常处理程序代码中将 EAX 设置为 -EFAULT。 好吧，如果用户访问成功，get_user() 宏实际上返回一个值：0，如果失败则返回 -EFAULT。 我们的原始代码没有测试此返回值，但是 get_user() 中的内联汇编代码尝试返回 -EFAULT。 GCC 选择 EAX 来返回此值。
注意：由于构建异常表的方式以及需要排序的方式，仅对 .text 节中的代码使用异常。 任何其他节都会导致异常表无法正确排序，并且异常将失败。
当向 x86 Linux 添加 64 位支持时，情况发生了变化。 不是通过将两个条目从 32 位扩展到 64 位来使异常表的大小加倍，而是使用了一个巧妙的技巧将地址存储为相对于表本身的偏移量。 汇编代码从
.long 1b,3b
to:
.long (from) - .
.long (to) - .
使用这些值的 C 代码转换回绝对地址，如下所示
ex_insn_addr(const struct exception_table_entry *x)
{
return (unsigned long)&x->insn + x->insn;
}
在 v4.6 中，异常表条目扩展了一个新字段“handler”。 这也是 32 位宽，包含第三个相对函数指针，该指针指向以下函数之一
int ex_handler_default(const struct exception_table_entry *fixup)这是仅跳转到 fixup 代码的遗留案例
int ex_handler_fault(const struct exception_table_entry *fixup)这种情况提供了在 entry->insn 处发生的陷阱的故障编号。 它用于区分页面错误和机器检查。
可以轻松添加更多功能。
CONFIG_BUILDTIME_TABLE_SORT 允许通过主机实用程序 scripts/sorttable 在内核映像的链接后对 __ex_table 节进行排序。 它会将符号 main_extable_sort_needed 设置为 0，从而避免在启动时对 __ex_table 节进行排序。 通过对异常表进行排序，在运行时发生异常时，我们可以通过二进制搜索快速查找 __ex_table 条目。
这不仅仅是启动时间优化，某些架构需要对该表进行排序才能在启动过程的相对早期处理异常。 例如，i386 在启用分页支持之前就使用了这种形式的异常处理！