Linux2.6对新型CPU的支持(2)

由用户态经库函数进入内核态

　　为了配合内核使用新的系统调用方式，glibc中要做一定的修改。新的glibc-2.3.2（及其以后版本中）中已经包含了这个改动，在glibc源代码的sysdeps/unix/sysv/linux/i386/sysdep.h文件中，处理系统调用的宏INTERNAL_SYSCALL在不同的编译选项下有不同的结果。在打开支持sysenter/sysexit指令的选项I386_USE_SYSENTER下，系统调用会有两种方式，在静态链接（编译时加上-static选项）情况下，采用"call *_dl_sysinfo"指令；在动态链接情况下，采用"call *%gs:0x10"指令。这两种情况由glibc库采用哪种方法链接，实际上最终都相当于调用某个固定地址的代码。下面我们通过一个小小的程序，配合gdb来验证。

　　首先是一个静态编译的程序，代码很简单：

　　main(){

　　getuid();}

　　将代码加上static选项用gcc静态编译，然后用gdb装载并反编译main函数。[root@test opt]# gcc test.c -o ./static -static[root@test opt]# gdb ./static(gdb) disassemble main0x08048204 <main+0>:

　　push

　　%ebp0x08048205 <main+1>:

　　mov

　　%esp,%ebp0x08048207 <main+3>:

　　sub

　　$0x8,%esp0x0804820a <main+6>:

　　and

　　$0xfffffff0,%esp0x0804820d <main+9>:

　　mov

　　$0x0,%eax0x08048212 <main+14>:

　　sub

　　%eax,%esp0x08048214 <main+16>:

　　call

　　0x804cb20 <__getuid>0x08048219 <main+21>:

　　leave0x0804821a <main+22>:

　　ret

　　可以看出，main函数中调用了__getuid函数，接着反编译__getuid函数。(gdb) disassemble 0x804cb200x0804cb20 <__getuid+0>:

　　push

　　%ebp0x0804cb21 <__getuid+1>:

　　mov

　　0x80aa028,%eax0x0804cb26 <__getuid+6>:

　　mov

　　%esp,%ebp0x0804cb28 <__getuid+8>:

　　test

　　%eax,%eax0x0804cb2a <__getuid+10>:

　　jle

　　0x804cb40 <__getuid+32>0x0804cb2c <__getuid+12>:

　　mov

　　$0x18,%eax0x0804cb31 <__getuid+17>:

　　call

　　*0x80aa0540x0804cb37 <__getuid+23>:

　　pop

　　%ebp0x0804cb38 <__getuid+24>:

　　ret

　　上面只是__getuid函数的一部分。可以看到__getuid将eax寄存器赋值为getuid系统调用的功能号0x18然后调用了另一个函数，这个函数的入口在哪里呢？接着查看位于地址0x80aa054的值。

　　

　　(gdb) X 0x80aa054

　　0x80aa054 <_dl_sysinfo>:

　　0x0804d7f6

　　看起来不像是指向内核映射页面内的代码，但是，可以确认，__dl_sysinfo指针的指向的地址就是0x80aa054。下面，我们试着启动这个程序，然后停在程序第一条语句，再查看这个地方的值。(gdb) b mainBreakpoint 1 at 0x804820a(gdb) rStarting program: /opt/staticBreakpoint 1, 0x0804820a in main ()(gdb) X 0x80aa0540x80aa054 <_dl_sysinfo>:

　　0xffffe400

　　可以看到，_dl_sysinfo指针指向的数值已经发生了变化，指向了0xffffe400，如果我们继续运行程序，__getuid函数将会调用地址0xffffe400处的代码。

　　接下来，我们将上面的代码编译成动态链接的方式，即默认方式，用gdb装载并反编译main函数[root@test opt]# gcc test.c -o ./dynamic[root@test opt]# gdb ./dynamic(gdb) disassemble main0x08048204 <main+0>:

　　push

　　%ebp0x08048205 <main+1>:

　　mov

　　%esp,%ebp0x08048207 <main+3>:

　　sub

　　$0x8,%esp0x0804820a <main+6>:

　　and

　　$0xfffffff0,%esp0x0804820d <main+9>:

　　mov

　　$0x0,%eax0x08048212 <main+14>:

　　sub

　　%eax,%esp0x08048214 <main+16>:

　　call

　　0x80482880x08048219 <main+21>:

　　leave0x0804821a <main+22>:

　　ret

　　由于libc库是在程序初始化时才被装载，所以我们先启动程序，并停在main第一条语句，然后反汇编getuid库函数。

　　(gdb) b mainBreakpoint 1 at 0x804820a(gdb) rStarting program: /opt/dynamicBreakpoint 1, 0x0804820a in main ()(gdb) disassemble getuidDump of assembler code for function getuid:0x40219e50 <__getuid+0>:

　　push

　　%ebp0x40219e51 <__getuid+1>:

　　mov

　　%esp,%ebp0x40219e53 <__getuid+3>:

　　push

　　%ebx0x40219e54 <__getuid+4>:

　　call

　　0x40219e59 <__getuid+9>0x40219e59 <__getuid+9>:

　　pop

　　%ebx0x40219e5a <__getuid+10>:

　　add

　　$0x84b0f,%ebx0x40219e60 <__getuid+16>:

　　mov

　　0xffffd87c(%ebx),%eax0x40219e66 <__getuid+22>:

　　test

　　%eax,%eax0x40219e68 <__getuid+24>:

　　jle

　　0x40219e80 <__getuid+48>0x40219e6a <__getuid+26>:

　　mov

　　$0x18,%eax0x40219e6f <__getuid+31>:

　　call

　　*%gs:0x100x40219e76 <__getuid+38>:

　　pop

　　%ebx0x40219e77 <__getuid+39>:

　　pop

　　%ebp0x40219e78 <__getuid+40>:

　　ret

　　可以看出，库函数getuid将eax寄存器设置为getuid系统调用的调用号0x18，然后调用%gs:0x10所指向的函数。在gdb中，无法查看非DS段的数据内容，所以无法查看%gs:0x10所保存的实际数值，不过我们可以通过编程的办法，内嵌汇编将%gs:0x10的值赋予某个局部变量来得到这个数值，而这个数值也是0xffffe400，具体代码这里就不再赘述。

　　

　　由此可见，无论是静态还是动态方式，最终我们都来到了0xffffe400这里的一段代码，这里就是内核为我们映射的系统调用入口代码。在gdb中，我们可以直接反汇编来查看这里的代码

　　(gdb) disassemble 0xffffe400 0xffffe414Dump of assembler code from 0xffffe400 to 0xffffe414:0xffffe400:

　　push

　　%ecx0xffffe401:

　　push

　　%edx0xffffe402:

　　push

　　%ebp0xffffe403:

　　mov

　　%esp,%ebp0xffffe405:

　　sysenter0xffffe407:

　　nop0xffffe408:

　　nop0xffffe409:

　　nop0xffffe40a:

　　nop0xffffe40b:

　　nop0xffffe40c:

　　nop0xffffe40d:

　　nop0xffffe40e:

　　jmp

　　0xffffe4030xffffe410:

　　pop

　　%ebp0xffffe411:

　　pop

　　%edx0xffffe412:

　　pop

　　%ecx0xffffe413:

　　retEnd of assembler dump.

　　这段代码正是arch/i386/kernel/vsyscall-sysenter.S文件中的代码。其中，在sysenter之前的是入口代码，在0xffffe410开始的是内核返回处理代码（后面提到的SYSENTER_RETURN即指向这里）。在入口代码中，首先是保存当前的ecx，edx（由于sysexit指令需要使用这两个寄存器）以及ebp。然后调用sysenter指令，跳转到内核Ring 0代码，也就是sysenter_entry入口处。

　　内核中的处理和返回

　　sysenter_entry整个的实现可以参见arch/i386/kernel/entry.S。内核处理SYSENTER的代码和处理INT的代码不太一样。通过sysenter指令进入Ring 0之后，由于当前的ESP并非指向正确的内核栈，而是当前CPU的TSS结构中的一个缓冲区（参见上文），所以首先要解决的是修复ESP，幸运的是，TSS结构中ESP0成员本身就保存有Ring 0状态的ESP值，所以在这里将TSS结构中ESP0的值赋予ESP寄存器。将ESP恢复成指向正确的堆栈之后，由于SYSENTER不是通过调用门进入Ring 0，所以在堆栈中的上下文和使用INT指令的不一样，INT指令进入Ring 0后栈中会保存如下的值。

　　低地址

　　返回用户态的EIP

　　用户态的CS

　　用户态的EFLAGS

　　用户态的ESP

　　用户态的SS（和DS相同）

　　高地址

　　因此，为了简化和重用代码，内核会用pushl指令往栈中放入上述各值，值得注意的是，内核在栈中放入的相对应用户态EIP的值，是一个代码标签SYSENTER_RETURN，在vsyscall-sysenter.S可以看到，它就在sysenter指令的后面（在它