Chinaunix首页 | 论坛 | 博客
  • 博客访问: 894710
  • 博文数量: 119
  • 博客积分: 2493
  • 博客等级: 大尉
  • 技术积分: 2363
  • 用 户 组: 普通用户
  • 注册时间: 2012-06-03 14:00
文章分类

全部博文(119)

文章存档

2013年(19)

2012年(100)

分类:

2012-07-16 10:03:03

from:


在  2.4 中,用户态 Ring3 请求内核态 Ring0 代码完成某些功能是通过调用完成的,而系统调用的是通过软中断指令(int 0x80)实现的。在 x86 保护中,处理 INT 中断指令时,CPU 首先从中断描述表 IDT 取出对应的门描述符,判断门描述符的种类,然后检查门描述符的级别 DPL 和 INT 指令调用者的级别 CPL,当 CPL<=DPL 也就是说 INT 调用者级别高于描述符指定级别时,才能成功调用,最后再根据描述符的内容,进行压栈、跳转、权限级别提升。内核代码执行完毕之后,调用 IRET 指令返回,IRET 指令恢复用户栈,并跳转会低级别的代码。

其实,在发生系统调用,由 Ring3 进入 Ring0 的这个过程浪费了不少的 CPU 周期,例如,系统调用必然需要由 Ring3 进入 Ring0(由内核调用 INT 指令的方式除外,这多半属于 Hacker 的内核模块所为),权限提升之前和之后的级别是固定的,CPL 肯定是 3,而 INT 80 的 DPL 肯定也是 3,这样 CPU 检查门描述符的 DPL 和调用者的 CPL 就是完全没必要。正是由于如此,Intel x86 CPU 从 PII 300(Family 6,Model 3,Stepping 3)之后,开始支持新的系统调用指令 sysenter/sy***it。sysenter 指令用于由 Ring3 进入 Ring0,SY***IT 指令用于由 Ring0 返回 Ring3。由于没有特权级别检查的处理,也没有压栈的操作,所以执行速度比 INT n/IRET 快了不少。

在 Intel 的者手册第二、三卷(Vol.2B,Vol.3)中,4.8.7 节是关于 sysenter/sy***it 指令的详细描述。手册中说明,sysenter 指令可用于特权级 3 的用户代码调用特权级 0 的系统内核代码,而 SY***IT 指令则用于特权级 0 的系统代码返回用户空间中。sysenter 指令可以在 3,2,1 这三个特权级别调用(Linux 中只用到了特权级 3),而 SY***IT 指令只能从特权级 0 调用。

执行 sysenter 指令的系统必须满足两个条件:1.目标 Ring 0 代码段必须是平坦模式(Flat Mode)的 4GB 的可读可执行的非一致代码段。2.目标 RING0 堆栈段必须是平坦模式(Flat Mode)的 4GB 的可读可写向上扩展的栈段。

在 Intel 的手册中,还提到了 sysenter/sy***it 和 int n/iret 指令的一个区别,那就是 sysenter/sy***it 指令并不成对,sysenter 指令并不会把 SY***IT 所需的返回地址压栈,sy***it 返回的地址并不一定是 sysenter 指令的下一个指令地址。调用 sysenter/sy***it 指令地址的跳转是通过设置一组特殊寄存器实现的。这些寄存器包括:

SYSENTER_CS_MSR - 用于指定要执行的 Ring 0 代码的代码段选择符,由它还能得出目标 Ring 0 所用堆栈段的段选择符;

SYSENTER_EIP_MSR - 用于指定要执行的 Ring 0 代码的起始地址;

SYSENTER_ESP_MSR-用于指定要执行的Ring 0代码所使用的栈指针

这些寄存器可以通过 wrmsr 指令来设置,执行 wrmsr 指令时,通过寄存器 edx、eax 指定设置的值,edx 指定值的高 32 位,eax 指定值的低 32 位,在设置上述寄存器时,edx 都是 0,通过寄存器 ecx 指定填充的 MSR 寄存器,sysenter_CS_MSR、sysenter_ESP_MSR、sysenter_EIP_MSR 寄存器分别对应 0x174、0x175、0x176,需要注意的是,wrmsr 指令只能在 Ring 0 执行。

这里还要介绍一个特性,就是 Ring0、Ring3 的代码段描述符和堆栈段描述符在全局描述符表 GDT 中是顺序排列的,这样只需知道 SYSENTER_CS_MSR 中指定的 Ring0 的代码段描述符,就可以推算出 Ring0 的堆栈段描述符以及 Ring3 的代码段描述符和堆栈段描述符。

在 Ring3 的代码调用了 sysenter 指令之后,CPU 会做出如下的操作:

1. 将 SYSENTER_CS_MSR 的值装载到 cs 寄存器

2. 将 SYSENTER_EIP_MSR 的值装载到 eip 寄存器

3. 将 SYSENTER_CS_MSR 的值加 8(Ring0 的堆栈段描述符)装载到 ss 寄存器。

4. 将 SYSENTER_ESP_MSR 的值装载到 esp 寄存器

5. 将特权级切换到 Ring0

6. 如果 EFLAGS 寄存器的 VM 标志被置位,则清除该标志

7. 开始执行指定的 Ring0 代码

在 Ring0 代码执行完毕,调用 SY***IT 指令退回 Ring3 时,CPU 会做出如下操作:

1. 将 SYSENTER_CS_MSR 的值加 16(Ring3 的代码段描述符)装载到 cs 寄存器

2. 将寄存器 edx 的值装载到 eip 寄存器

3. 将 SYSENTER_CS_MSR 的值加 24(Ring3 的堆栈段描述符)装载到 ss 寄存器

4. 将寄存器 ecx 的值装载到 esp 寄存器

5. 将特权级切换到 Ring3

6. 继续执行 Ring3 的代码

由此可知,在调用 SYSENTER 进入 Ring0 之前,一定需要通过 wrmsr 指令设置好 Ring0 代码的相关信息,在调用 SY***IT 之前,还要保证寄存器edx、ecx 的正确性。

根据 Intel 的 CPU 手册,我们可以通过 CPUID 指令来查看 CPU 是否支持 sysenter/sy***it 指令,做法是将 EAX 寄存器赋值 1,调用 CPUID 指令,寄存器 edx 中第 11 位(这一位名称为 SEP)就表示是否支持。在调用 CPUID 指令之后,还需要查看 CPU 的 Family、Model、Stepping 属性来确认,因为据称 Pentium Pro 处理器会报告 SEP 但是却不支持 sysenter/sy***it 指令。只有 Family 大于等于 6,Model 大于等于 3,Stepping 大于等于 3 的时候,才能确认 CPU 支持 sysenter/sy***it 指令。

在 2.4 内核中,直到最近的发布的 2.4.26-rc2 版本,没有加入对 sysenter/sy***it 指令的支持。而对 sysenter/sy***it 指令的支持最早是2002 年,由 Linus Torvalds 编写并首次加入 2.5 版内核中的,经过多方测试和多次 patch,最终正式加入到了 2.6 版本的内核中。

具体谈到系统调用的完成,不能孤立的看内核的代码,我们知道,系统调用多被封装成库提供给程序调用,应用程序调用库函数后,由 glibc 库负责进入内核调用系统调用函数。在 2.4 内核加上老版的 glibc 的情况下,库函数所做的就是通过 int 指令来完成系统调用,而内核提供的系统调用接口很简单,只要在 IDT 中提供 INT 0x80 的入口,库就可以完成中断调用。

在 2.6 内核中,内核代码同时包含了对 int 0x80 中断方式和 sysenter 指令方式调用的支持,因此内核会给用户空间提供一段入口代码,内核启动时根据 CPU 类型,决定这段代码采取哪种系统调用方式。对于 glibc 来说,无需考虑系统调用方式,直接调用这段入口代码,即可完成系统调用。这样做还可以尽量减少对 glibc 的改动,在 glibc 的源码中,只需将 "int $0x80" 指令替换成 "call 入口地址" 即可。

下面,以 2.6.0 的内核代码配合支持 SYSENTER 调用方式的 glibc2.3.3 为例,分析一下系统调用的具体实现。

前面说到的这段入口代码,根据调用方式分为两个文件,支持 sysenter 指令的代码包含在文件 arch/i386/kernel/vsyscall-sysenter.S 中,支持int中断的代码包含在arch/i386/kernel/vsyscall-int80.S中,入口名都是__kernel_vsyscall,这两个文件编译出的二进制代码由arch/i386/kernel/vsyscall.S所包含,并导出起始地址和结束地址。

2.6内核在启动的时候,调用了新增的函数sysenter_setup(参见arch/i386/kernel/sysenter.c),在这个函数中,内核将虚拟内存空间的顶端一个固定地址页面(从0xffffe000开始到0xffffeffff的4k大小)映射到一个空闲的物理内存页面。然后通过之前执行CPUID的指令得到的数据,检测CPU是否支持sysenter/sy***it指令。如果CPU不支持,那么将采用INT调用方式的入口代码拷贝到这个页面中,然后返回。相反,如果CPU支持SYSETER/SY***IT指令,则将采用SYSENTER调用方式的入口代码拷贝到这个页面中。使用宏on_each_cpu在每个CPU上执行enable_sep_cpu这个函数。

在enable_sep_cpu函数中,内核将当前CPU的TSS结构中的ss1设置为当前内核使用的代码段,esp1设置为该TSS结构中保留的一个256字节大小的堆栈。在X86中,TSS结构中ss1和esp1本来是用于保存Ring 1进程的堆栈段和堆栈指针的。由于内核在启动时,并不能预知调用sysenter指令进入Ring 0后esp的确切值,而应用程序又无权调用wrmsr指令动态设置,所以此时就借用esp1指向一个固定的缓冲区来填充这个MSR寄存器,由于Ring 1根本没被启用,所以并不会对系统造成任何影响。在下面的文章中会介绍进入Ring 0之后,内核如何修复ESP来指向正确的Ring 0堆栈。关于TSS结构更细节的应用可参考代码include/asm-i386/processor.h)。

然后,内核通过wrmsr(msr,val1,val2)宏调用wrmsr指令对当前CPU设置MSR寄存器,可以看出调用宏的第三个参数即edx都被设置为0。其中SYSENTER_CS_MSR的值被设置为当前内核用的所在代码段;SYSENTER_ESP_MSR被设置为esp1,即指向当前CPU的TSS结构中的堆栈;SYSENTER_EIP_MSR则被设置为内核中处理sysenter指令的接口函数sysenter_entry(参见arch/i386/kernel/entry.S)。这样,sysenter指令的准备工作就完成了。

通过内核在启动时进行这样的设置,在每个进程的进程空间中,都能访问到内核所映射的这个代码页面,当然这个页面对于应用程序来说是只读的。我们通过新版的ldd工具查看任意一个可执行程序,可以看到下面的结果:

[root@test]# file dynamic dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped [root@test]# ldd dynamic linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/libc.so.6 (0x4002c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

这个所谓的"linux-gate.so.1"的内容就是内核映射的代码,系统中其实并不存在这样一个链接库文件,它的名字是由ldd自己起的,而在老版本的ldd中,虽然能够检测到这段代码,但是由于没有命名而且在系统中找不到对应链接库文件,所以会有一些显示上的问题。有关这个问题的背景,可以参考下面这个网址:。

为了配合内核使用新的系统调用方式,glibc中要做一定的修改。新的glibc-2.3.2(及其以后版本中)中已经包含了这个改动,在glibc源代码的sysdeps/unix/sysv/linux/i386/sysdep.h文件中,处理系统调用的宏INTERNAL_SYSCALL在不同的编译选项下有不同的结果。在打开支持sysenter/sy***it指令的选项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(由于sy***it指令需要使用这两个寄存器)以及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寄存器,调用SY***IT指令返回用户态。返回用户态之后,从栈中取出ESP,edx,ecx,最终返回glibc库。

以及其它硬件平台的支持

值得一提的是,从  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/sy***it 指令。在 Linux 内核针对 AMD64 架构的代码中,采用的还是 SYSCALL/SYSRET 指令。至于这两种指令最终谁将成为标准,目前还无法得出结论。

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

阅读(3379) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~