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

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 main

0x08048204 :　　push　 %ebp

0x08048205 :　　mov　　%esp,%ebp

0x08048207 :　　sub　　$0x8,%esp

0x0804820a :　　and　　$0xfffffff0,%esp

0x0804820d :　　mov　　$0x0,%eax

0x08048212 :　 sub　　%eax,%esp

0x08048214 :　 call　 0x804cb20 <__getuid>

0x08048219 :　 leave

0x0804821a :　 ret

　　可以看出，main函数中调用了__getuid函数，接着反编译__getuid函数。

(gdb) disassemble 0x804cb20

0x0804cb20 <__getuid>:　　　　push　 %ebp

0x0804cb21 <__getuid>:　　　　mov　　0x80aa028,%eax

0x0804cb26 <__getuid>:　　　　mov　　%esp,%ebp

0x0804cb28 <__getuid>:　　　　test　 %eax,%eax

0x0804cb2a <__getuid>:　　　 jle　　0x804cb40 <__getuid>

0x0804cb2c <__getuid>:　　　 mov　　$0x18,%eax

0x0804cb31 <__getuid>:　　　 call　 *0x80aa054

0x0804cb37 <__getuid>:　　　 pop　　%ebp

0x0804cb38 <__getuid>:　　　 ret

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

　　(gdb) X 0x80aa054

　　0x80aa054 <_dl_sysinfo>:　　　　0x0804d7f6

　　看起来不像是指向内核映射页面内的代码，但是，可以确认，__dl_sysinfo指针的指向的地址就是0x80aa054。下面，我们试着启动这个程序，然后停在程序第一条语句，再查看这个地方的值。

(gdb) b main

Breakpoint 1 at 0x804820a

(gdb) r

Starting program: /opt/static

Breakpoint 1, 0x0804820a in main ()

(gdb) X 0x80aa054

0x80aa054 <_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 main

0x08048204 :　　push　 %ebp

0x08048205 :　　mov　　%esp,%ebp

0x08048207 :　　sub　　$0x8,%esp

0x0804820a :　　and　　$0xfffffff0,%esp

0x0804820d :　　mov　　$0x0,%eax

0x08048212 :　 sub　　%eax,%esp

0x08048214 :　 call　 0x8048288

0x08048219 :　 leave

0x0804821a :　 ret

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

　　(gdb) b main

Breakpoint 1 at 0x804820a

(gdb) r

Starting program: /opt/dynamic

Breakpoint 1, 0x0804820a in main ()

(gdb) disassemble getuid

Dump of assembler code for function getuid:

0x40219e50 <__getuid>:　　　　push　 %ebp

0x40219e51 <__getuid>:　　　　mov　　%esp,%ebp

0x40219e53 <__getuid>:　　　　push　 %ebx

0x40219e54 <__getuid>:　　　　call　 0x40219e59 <__getuid>

0x40219e59 <__getuid>:　　　　pop　　%ebx

0x40219e5a <__getuid>:　　　 add　　$0x84b0f,%ebx

0x40219e60 <__getuid>:　　　 mov　　0xffffd87c(%ebx),%eax

0x40219e66 <__getuid>:　　　 test　 %eax,%eax

0x40219e68 <__getuid>:　　　 jle　　0x40219e80 <__getuid>

0x40219e6a <__getuid>:　　　 mov　　$0x18,%eax

0x40219e6f <__getuid>:　　　 call　 *%gs:0x10

0x40219e76 <__getuid>:　　　 pop　　%ebx

0x40219e77 <__getuid>:　　　 pop　　%ebp

0x40219e78 <__getuid>:　　　 ret

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

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

　　(gdb) disassemble 0xffffe400 0xffffe414

Dump of assembler code from 0xffffe400 to 0xffffe414:

0xffffe400:　　 push　 %ecx

0xffffe401:　　 push　 %edx

0xffffe402:　　 push　 %ebp

0xffffe403:　　 mov　　%esp,%ebp

0xffffe405:　　 sysenter

0xffffe407:　　 nop

0xffffe408:　　 nop

0xffffe409:　　 nop

0xffffe40a:　　 nop

0xffffe40b:　　 nop

0xffffe40c:　　 nop

0xffffe40d:　　 nop

0xffffe40e:　　 jmp　　0xffffe403

0xffffe410:　　 pop　　%ebp

0xffffe411:　　 pop　　%edx

0xffffe412:　　 pop　　%ecx

0xffffe413:　　 ret

End 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指令的后面（在它们之间，有一段NOP，是内核返回出错时的处理代码）。接下来，处理系统调用的代码就和中断方式的处理代码一模一样了，内核保存所有的寄存器，然后系统调用表找到对应系统调用的入口，完成调用。最后，内核从栈中取出前面存入的用户态的EIP和ESP，存入edx和ecx寄存器，调用SYSEXIT指令返回用户态。返回用户态之后，从栈中取出ESP，edx，ecx，最终返回glibc库。

　　其它操作系统以及其它硬件平台的支持

　　值得一提的是，从 Windows XP 开始，Windows 的系统调用方式也从软中断 int 0x2e 转换到采用 sysenter 方式，由于完全不再支持 int 方式，因此 Windows XP 的对 CPU 的最低配置要求是 PentiumII 300MHz。在其它的操作系统例如 *BSD 系列，目前并没有提供对 sysenter 指令的支持。

　　在 CPU 方面，AMD 的 CPU 支持一套与之对应的指令 SYSCALL/SYSRET。在纯 32 位的 AMD CPU 上，还没有支持 sysenter 指令，而在 AMD 推出的 AMD64 系列 CPU 上，处于某些模式的情况下，CPU 能够支持 sysenter/sysexit 指令。在 Linux 内核针对 AMD64 架构的代码中，采用的还是 SYSCALL/SYSRET 指令。至于这两种指令最终谁将成为标准，目前还无法得出结论。

　　未来

　　我们将 Intel 的 sysenter/sysexit 指令，AMD 的 SYSCALL/SYSRET 指令统称为"快速系统调用指令"。"快速系统调用指令"比起中断指令来说，其消耗时间必然会少一些，但是随着 CPU 设计的发展，将来应该不会再出现类似 Intel Pentium4 这样悬殊的差距。而"快速系统调用指令"比起中断方式的系统调用方式，还存在一定局限，例如无法在一个系统调用处理过程中再通过"快速系统调用指令"调用别的系统调用。因此，并不一定每个系统调用都需要通过"快速系统调用指令"来实现。比如，对于复杂的系统调用例如 fork，两种系统调用方式的时间差和系统调用本身运行消耗的时间来比，可以忽略不计，此处采取"快速系统调用指令"方式没有什么必要。而真正应该使用"快速系统调用指令"方式的，是那些本身运行时间很短，对时间精确性要求高的系统调用，例如 getuid、gettimeofday 等等。因此，采取灵活的手段，针对不同的系统调用采取不同的方式，才能得到最优化的性能和实现最完美的功能。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14102/viewspace-116298/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14102/viewspace-116298/