来自 Joerg Pommnitz 于 1996 年 11 月 11 日发给 linux-kernel 邮件列表的消息，已编辑。根据 Linus Torvalds 的说法
对底层可怕的东西感兴趣的人应该看看 x86 或 alpha 的 uaccess.h 文件，并准备花一些时间弄清楚这一切是做什么的;)
我就是，而且我做了。
当进程在内核模式下运行时，它经常需要访问用户模式内存，其地址由不受信任的程序传递。为了保护自己，内核必须验证这个地址。
在旧版本的 Linux 中，这是通过
int verify_area(int type, const void * addr, unsigned long size)函数完成的。
此函数验证了从地址addr开始且大小为size的内存区域对于在type(读取或写入) 中指定的操作是否可访问。为此，verify_read必须查找包含地址的虚拟内存区域 (vma)addr。在正常情况下 (正确工作的程序)，此测试是成功的。它仅在 (希望是) 罕见的、有缺陷的程序中失败。在一些内核性能分析测试中，这种通常不需要的验证占用了相当多的时间。
为了克服这种情况，Linus 决定让每个支持 Linux 的 CPU 中存在的虚拟内存硬件来处理此测试。
每当内核尝试访问当前不可访问的地址时，CPU 都会生成页面错误异常并调用页面错误处理程序，
void do_page_fault(struct pt_regs *regs, unsigned long error_code)该处理程序位于 arch/i386/mm/fault.c 中。堆栈上的参数由 arch/i386/kernel/entry.S 中的底层汇编粘合代码设置。参数regs是指向堆栈上已保存寄存器的指针，error_code包含异常的原因代码。
do_page_fault首先从 CPU 控制寄存器 CR2 获取不可访问的地址。如果该地址在进程的虚拟地址空间内，则可能发生错误，因为该页面未被换入、写保护或类似情况。但是，我们对另一种情况感兴趣：地址无效，没有vma包含此地址的 vma。在这种情况下，内核跳转到bad_area标签。
在那里，它使用导致异常的指令的地址 (即regs->eip) 来查找可以继续执行的地址 (fixup)。如果此搜索成功，则错误处理程序修改返回地址 (再次为regs->eipregs->eip
fixup 指向哪里？由于我们跳转到 fixup 的内容，fixup 显然指向可执行代码。此代码隐藏在用户访问宏中。我选择了 include/asm/uaccess.h 中定义的get_user由于我们跳转到 fixup 的内容，fixup 显然指向可执行代码。此代码隐藏在用户访问宏中。我选择了 include/asm/uaccess.h 中定义的宏作为示例。定义有点难以理解，所以让我们看一下预处理器和编译器生成的代码。我选择了 drivers/char/console.c 中的
调用进行详细检查。
get_user(c, buf);console.c 第 1405 行的原始代码
(
{
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;
}
);
预处理器输出 (已编辑为更具可读性) 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
哇！黑色 GCC/汇编魔法。这不可能理解，所以让我们看看 gcc 生成了什么代码优化器做得很好，给了我们一些我们实际上可以理解的东西。我们可以吗？实际的用户访问非常明显。由于统一的地址空间，我们可以直接访问用户内存中的地址。但是.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
为了理解这一点，我们必须查看最终的内核$ 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在生成的对象文件中显然有 2 个非标准的 ELF section。但首先我们要找出我们的代码在最终的内核可执行文件中发生了什么优化器做得很好，给了我们一些我们实际上可以理解的东西。我们可以吗？实际的用户访问非常明显。由于统一的地址空间，我们可以直接访问用户内存中的地址。但是整个用户内存访问被简化为 10 条 x86 机器指令。括号在
$ 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>.section .fixup,"ax"
$ objdump --full-contents --section=__ex_table vmlinux c01aa7c4 93c017c0 e09f19c0 97c017c0 99c017c0 ................ c01aa7d4 f6c217c0 e99f19c0 a5e717c0 f59f19c0 ................ c01aa7e4 080a18c0 01a019c0 0a0a18c0 04a019c0 ................指令中的指令不再在正常的执行路径中。它们位于可执行文件的不同 section 中
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"或以人类可读的字节顺序
3: movl $-14,%eax
xorb %dl,%dl
jmp 2b
发生了什么？汇编指令.section .fixup,"ax",@progbits.previous.long 1b,3b发生了什么？汇编指令.section __ex_table,"a".previous告诉汇编器将以下代码移动到 ELF 对象文件中指定的 section。所以指令3: movl $-14,%eaxended up in the.fixup告诉汇编器将以下代码移动到 ELF 对象文件中指定的 section。所以指令 (告诉汇编器将以下代码移动到 ELF 对象文件中指定的 section。所以指令section of the object file and the addresses1b:
1: movb (%ebx),%dl
c017e7a5 <do_con_write+e1> movb (%ebx),%dl
c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
.section __ex_table,"a"
.align 4
.long 1b,3b
(表示下一个标签 1 向后) 是可能发生错误的指令的地址。在我们的例子中，标签 1b 的地址是c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
^this is ^this is
1b 3b
1b,3bc017e7a5原始汇编代码并且链接到 vmlinux 中局部标签 3 (再次向后) 是处理错误的code的地址，在我们的例子中，实际值是.section __ex_table,"a"c0199ff53: movl $-14,%eax3: movl $-14,%eax汇编代码3: movl $-14,%eax并且链接到 vmlinux 中becomes the value pair成为内核异常表中的值对。3: movl $-14,%eax为了使函数
在vmasection 中找到异常表，它使用链接器功能：每当链接器看到一个section，其整个名称是有效的 C 标识符时，它会创建符号
c017e7a5 <do_con_write+e1> movb (%ebx),%dl
(即 ELF section会发生什么？__ex_tableMMU 生成异常的内容)由于我们跳转到 fixup 的内容，fixup 显然指向可执行代码。此代码隐藏在用户访问宏中。我选择了 include/asm/uaccess.h 中定义的并返回关联的错误处理代码的地址MMU 生成异常修改其自身的返回地址以指向错误处理代码并返回。由于我们跳转到 fixup 的内容，fixup 显然指向可执行代码。此代码隐藏在用户访问宏中。我选择了 include/asm/uaccess.h 中定义的执行在错误处理代码中继续进行。MMU 生成异常8a)会发生什么？EAX
Joerg Pommnitz | joerg@raleigh.ibm.com | Never attribute to malloc Mobile/Wireless | Dept UMRA | that which can be adequately Tel:(919)254-6397 | Office B502/E117 | explained by stupidity.