5. 内核级异常处理¶
Joerg Pommnitz 评注 <joerg@raleigh.ibm.com>
当进程在内核模式下运行时，它经常需要访问其地址由不受信任的程序传递的用户模式内存。为了保护自身，内核必须验证这个地址。
在旧版本的 Linux 中，这是通过 int verify_area(int type, const void * addr, unsigned long size) 函数完成的（该函数此后已被 access_ok() 取代）。
此函数验证从地址 ‘addr’ 开始、大小为 ‘size’ 的内存区域对于 type 指定的操作（读或写）是否可访问。为此，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
在生成的目标文件中显然有 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()在异常表中查找地址 c017e7a5（即 ELF 段 __ex_table 的内容）并返回相关故障处理代码的地址 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 甚至在启用分页支持之前就已经利用了这种形式的异常处理！