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 的东西是做什么的？？？？？
要理解这一点，我们必须查看最终的内核
> 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
在生成的对象文件中，显然有两个非标准的 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 在启用分页支持之前就使用了这种形式的异常处理！