Linux-gate.so技术细节

1. linux-gate.so是什么
参考这里:http://www.trilithium.com/johan/2005/08/linux-gate/

简而言之,linux-gate.so是为了实现用户程序使用sysenter/sysexit进行
系统调用的辅助机制。为什么我们需要这么一种机制来完成sysenter/sysexit?

按照我们使用int 80进行系统调用的思维,我们期待sysenter/sysexit是这样的
一个过程:
          
          user app:                        kernel:
            /*things*/                     
            /*setup parameters*/
            movl $__NR_getpid, %eax
            sysenter                ------>
                                           movl current->pid, %eax
                                           sysexit
                                    <------
            /*%eax=pid*/
            /*other things*/

我们编写一个例子试试上面的想法:

    [root@w237 vdso.d]# cat pid.c

    #include <stdio.h>
    #include <sys/types.h>
    #include <unistd.h>
    #include <sys/syscall.h>
    
    #define STRINGFY_(x) #x
    #define STRINGFY(x) STRINGFY_(x)
    
    int main()
    {
        pid_t pid;
    
        __asm__ volatile("movl $"STRINGFY(__NR_getpid)", %%eax\n"
                         "sysenter\n"
                         : "=a"(pid));
        printf("pid=%u\n", pid);
    
        return 0;
    }

编译,gdb调试:
    [root@w237 vdso.d]# gcc -g -o pid pid.c
    [root@w237 vdso.d]# gdb -q ./pid
    Using host libthread_db library "/lib/tls/libthread_db.so.1".
    (gdb) disassemble main
    Dump of assembler code for function main:
    0x08048368 <main+0>:    push   %ebp
    0x08048369 <main+1>:    mov    %esp,%ebp
    0x0804836b <main+3>:    sub    $0x8,%esp
    0x0804836e <main+6>:    and    $0xfffffff0,%esp
    0x08048371 <main+9>:    mov    $0x0,%eax
    0x08048376 <main+14>:   add    $0xf,%eax
    0x08048379 <main+17>:   add    $0xf,%eax
    0x0804837c <main+20>:   shr    $0x4,%eax
    0x0804837f <main+23>:   shl    $0x4,%eax
    0x08048382 <main+26>:   sub    %eax,%esp
    0x08048384 <main+28>:   mov    $0x14,%eax
    0x08048389 <main+33>:   sysenter
    0x0804838b <main+35>:   mov    %eax,0xfffffffc(%ebp)
    0x0804838e <main+38>:   sub    $0x8,%esp
    0x08048391 <main+41>:   pushl  0xfffffffc(%ebp)
    0x08048394 <main+44>:   push   $0x8048488
    0x08048399 <main+49>:   call   0x80482b0
    0x0804839e <main+54>:   add    $0x10,%esp
    0x080483a1 <main+57>:   mov    $0x0,%eax
    0x080483a6 <main+62>:   leave
    0x080483a7 <main+63>:   ret
    End of assembler dump.
    (gdb)
我们在sysenter一行设置断点,并且运行跟踪:
    (gdb) b *0x8048389
    Breakpoint 1 at 0x8048389: file pid.c, line 13.
    (gdb) r
    Starting program: /home/wensg/vdso.d/pid
    Reading symbols from shared object read from target memory...done.
    Loaded system supplied DSO at 0xffffe000
    
    Breakpoint 1, 0x08048389 in main () at pid.c:13
    13          __asm__ volatile("movl $"STRINGFY(__NR_getpid)", %%eax\n"
这时候gdb中断在sysenter这一行,用stepi单步运行这条指令:
    (gdb) stepi
    0xffffe424 in __kernel_vsyscall ()
看见了么?当sysenter执行完毕(也就是sysexit的结果)以后,程序是停在了0xffffe424这一行,
这个地址位于函数__kernel_vsyscall中!!为什么不是sysenter的下一行0x804838b???

2. sysenter/sysexit指令

参考IA32的文档。

sysenter/sysexit被冠以“Fast System Call facility”。至于是否如此,我现在不关心。

sysenter调用的过程为:
设置下面寄存器值(%msr[SYSENTER_CS]表示名为SYSENTER_CS的msr值,model specific 
register,一组特别的寄存器组):
    %cs   = %msr[SYSENTER_CS]
    %eip  = %msr[SYSENTER_EIP]
    %ss   = %msr[SYSENTER_SS] + 8
    %esp  = %msr[SYSENTER_ESP]
    %CPL  = 0
然后从%cs:%eip继续执行。

sysexit调用过程为:
设置下面寄存器值:
    %cs   = %msr[SYSENTER_CS] + 16
    %eip  = %edx
    %ss   = %msr[SYSENTER_CS] + 24
    %esp  = %ecx
    %CPL  = 3
然后从%cs:%eip继续执行。

我们看到sysenter调用进入内核时,CPU不会保存用户堆栈,返回地址和其它的寄存器,
那么sysexit怎么返回到正确的用户空间呢?

一种办法就是调用前把%eip, %esp(因为%cs, %ss只是内核用来糊弄MMU的,我们先不管了)
保存在别的寄存器中,不过这样需要2个寄存器才能完成任务。

另外一种办法就是sysexit总是返回到用户进程某个固定的地址!vdso就是作为
sysenter/sysexit的存根(stub)的。sysenter只会在某个固定的位置被调用,而sysexit
也只需要返回到调用sysenter+2的位置(sysenter的机器码占2个字节)。不过%esp还是
需要保存的。

这就是为什么我们在例子1中观察到了sysenter指令会跳转到了__kernel_vsyscall()函数中,
sysexit返回的固定地址就在这个__kernel_vsyscall中。

让我们看看__kernel_vsyscall的汇编代码:
    (gdb) disassemble __kernel_vsyscall
    Dump of assembler code for function __kernel_vsyscall:
    0xffffe414 <__kernel_vsyscall+0>:       push   %ecx
    0xffffe415 <__kernel_vsyscall+1>:       push   %edx
    0xffffe416 <__kernel_vsyscall+2>:       push   %ebp
    0xffffe417 <__kernel_vsyscall+3>:       mov    %esp,%ebp
    0xffffe419 <__kernel_vsyscall+5>:       sysenter
    0xffffe41b <__kernel_vsyscall+7>:       nop
    0xffffe41c <__kernel_vsyscall+8>:       nop
    0xffffe41d <__kernel_vsyscall+9>:       nop
    0xffffe41e <__kernel_vsyscall+10>:      nop
    0xffffe41f <__kernel_vsyscall+11>:      nop
    0xffffe420 <__kernel_vsyscall+12>:      nop
    0xffffe421 <__kernel_vsyscall+13>:      nop
    0xffffe422 <__kernel_vsyscall+14>:      jmp    0xffffe417 <__kernel_vsyscall+3>
    0xffffe424 <__kernel_vsyscall+16>:      pop    %ebp  ; sysexit返回到这里
    0xffffe425 <__kernel_vsyscall+17>:      pop    %edx
    0xffffe426 <__kernel_vsyscall+18>:      pop    %ecx
    0xffffe427 <__kernel_vsyscall+19>:      ret
    End of assembler dump.
    (gdb)
看到没有,在0xffffe424这一行的上方有一个sysenter指令。Linux的设计是:进程只应当
从一个地方调用sysenter, sysexit返回到这个调用下面的某个地方,这两个地址都是固定的。
__kernel_vsyscall的sysenter到sysexit返回的地址0xffffe424中间有数个nop和jmp指令
的作用,下面再解释。

3. 如何使用sysenter

从例1的例子来看,我们是无法直接使用sysenter的,因为我们无法知道这个返回地址和
调用的协议。实际上,这样的指令对于普通的程序员来说,完全是透明的。vdso是C库的开发
者关心的问题。

__kernel_vsyscall的设计目标是代替int 80, 也就是下面两种方式应该是等价的:
     /* int80 */                  /* __kernel_vsyscall */
     movl $__NR_getpid, %eax      movl $__NR_getpid, %eax
     int $0x80                    call __kernel_vsyscall
     /* %eax=getpid() */          /* %eax=getpid() %/

C库有怎么知道有__kernel_vsyscall呢?很简单,kernel告诉C库,kernel中存在
__kernel_vsyscall。至于C库选择int80,还是sysenter进行系统调用,那就是C库管了,
kernel已经提供了这样的一种机制,策略就不管是它管的了。

kernel告诉C库__kernel_vsyscall的位置,则是通过elf的interpreter的auxiliary vector
这个的具体细节看以参考elf的技术文档,我们可以通过下面的手段观察auxiliary vector
    [root@w237 vdso.d]# LD_SHOW_AUXV=1 /bin/ls
    AT_SYSINFO:      0xffffe414
    AT_SYSINFO_EHDR: 0xffffe000
    AT_HWCAP:    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
    AT_PAGESZ:       4096
    AT_CLKTCK:       100
    AT_PHDR:         0x8048034
    AT_PHENT:        32
    AT_PHNUM:        8
    AT_BASE:         0x0
    AT_FLAGS:        0x0
    AT_ENTRY:        0x8049cf0
    AT_UID:          0
    AT_EUID:         0
    AT_GID:          0
    AT_EGID:         0
    AT_SECURE:       0
    AT_PLATFORM:     i686
AT_SYSINFO就是__kernel_vsyscall函数的地址,AT_SYSINFO_EHDR是vdso加载的位置。

4. 总体的结构:

用下面的图来解释:
 这张图不清楚,贴一张真正的图:


linux-gate.so(vdso)是内核镜像中的特定页,它是一个完整的elf share object,
因此在磁盘的任何位置都找不到一个它。它是由内核的某些文件编译生成的。

当使用exec()执行新的镜像时,内核把linux-gate.so的页面映射到程序的进程空间中。
内核把__kernel_vsyscall的地址以auxiliary vector的形式告诉interpreter
(C库)。

当C库要进入内核时,它就可以选择使用__kernel_vsyscall或者int80来进行系统调用。

5. 内核的细节

让我们想想内核需要做那些工作:
  5.1 生成vdso,并链接到内核中。
  5.2 设置MSR,以便sysenter能进入内核的正确位置,sysexit能返回到用户程序的正确位置。
  5.3 exec()时,将vdso映射到用户程序的地址空间中,找到__kernel_vsyscall的地址,
      传给interpreter。
  5.4 调用时,正确传递参数。
  5.5 sysenter的响应函数要正确解析参数,调用相应的系统函数完成服务;设置%ecx, %edx,
      用sysexit返回
  5.6 当程序exit时,解除vdso的映射。
 
当你理解上面的内容之后,理解内核的细节不过是把它们找出来而已。自己去翻内核看,也是理解
上面内容的一个很好的途径。

6. __kernel_vsyscall

前面还遗留了一个问题,那7个nop和jmp是干什么的呢?让我们再看看它的代码:
    0xffffe414 <__kernel_vsyscall+0>:       push   %ecx
    0xffffe415 <__kernel_vsyscall+1>:       push   %edx
    0xffffe416 <__kernel_vsyscall+2>:       push   %ebp
    0xffffe417 <__kernel_vsyscall+3>:       mov    %esp,%ebp
    0xffffe419 <__kernel_vsyscall+5>:       sysenter
    0xffffe41b <__kernel_vsyscall+7>:       nop
    0xffffe41c <__kernel_vsyscall+8>:       nop
    0xffffe41d <__kernel_vsyscall+9>:       nop
    0xffffe41e <__kernel_vsyscall+10>:      nop
    0xffffe41f <__kernel_vsyscall+11>:      nop
    0xffffe420 <__kernel_vsyscall+12>:      nop
    0xffffe421 <__kernel_vsyscall+13>:      nop
    0xffffe422 <__kernel_vsyscall+14>:      jmp    0xffffe417 <__kernel_vsyscall+3>
    0xffffe424 <__kernel_vsyscall+16>:      pop    %ebp  ; sysexit返回到这里
    0xffffe425 <__kernel_vsyscall+17>:      pop    %edx
    0xffffe426 <__kernel_vsyscall+18>:      pop    %ecx
    0xffffe427 <__kernel_vsyscall+19>:      ret

前面连个push %ecx和%edx是因为sysexit返回时,要用这两个寄存器来制定返回的eip和esp,因此先保存起来。
然后我们要把%esp的值保存在%ebp中,否则我们就无法获得当前的堆栈指针了,在覆盖%ebp前,先保存%ebp,
这是系统调用的第六个参数。
然后使用sysenter
然后一堆的nop和一个jmp,这里完全是一个死循环。这是干什么的?正常的sysexit又不会执行这里(直接到
jmp之后了)

这个问题linus在这封mail中讨论了:
http://lkml.org/lkml/2002/12/18/218
他的意思是jmp的设计是用来支持restarted system call的,如果一个system call需要restart,它只需要返
回到某个nop中,然后jmp到重新初始化%ebp的代码中,从而是sysenter再次执行。
不过什么情况下会使一个system call restart,征个人告诉我。

 

下面link也不错,可对照参考一下;

http://www.ibm.com/developerworks/cn/linux/kernel/l-k26ncpu/index.html
Linux 2.6 对新型 CPU 快速系统调用的支持

posted @ 2016-12-11 13:40  VinoZhu  阅读(1967)  评论(0编辑  收藏  举报