ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Linux2.6对新型CPU的支持(2)(转)

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

原创 Linux操作系统 作者:ilg 时间:2019-02-27 14:39:05 0 删除 编辑
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+0>:    push  %ebp

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

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

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

0x0804cb2a <__getuid+10>:    jle  0x804cb40 <__getuid+32>

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

0x0804cb31 <__getuid+17>:    call  *0x80aa054

0x0804cb37 <__getuid+23>:    pop  %ebp

0x0804cb38 <__getuid+24>:    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+0>:    push  %ebp

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

0x40219e53 <__getuid+3>:    push  %ebx

0x40219e54 <__getuid+4>:    call  0x40219e59 <__getuid+9>

0x40219e59 <__getuid+9>:    pop  %ebx

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

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

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

0x40219e68 <__getuid+24>:    jle  0x40219e80 <__getuid+48>

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

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

0x40219e76 <__getuid+38>:    pop  %ebx

0x40219e77 <__getuid+39>:    pop  %ebp

0x40219e78 <__getuid+40>:    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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2002-06-18

  • 博文量
    1715
  • 访问量
    1300035