久久精品www人人爽人人,精品久久久无码中文字幕,99久久免费国产精品

linux信号机制 �Q?用户堆栈和内核堆栈的变化

hex108 — Tue, 26 Jul 2011 10:27:00 GMT

此文只简单分析发送信��L��用户�E�序后，用户堆栈和内核堆栈的变化。没有分析实时信��P��当然整个�q�程基本一致。很多参考了�Q�情景分析＞�Q�所以有些代码和现在的内核可能不同，比如RESTORE_ALL�Q�但大体的机制是�c�M��的�?br />
1. 一个信号小例子

hex@Gentoo ~/signal $ cat sigint.c
#include
#include
#include

void sig_int(int signo)
{
    printf("hello\n");
}

int main()
{
    if(signal(SIGINT, sig_int) == SIG_ERR){
        printf("can't catch SIGINT\n");
        exit(-1);
    }

    for(;;)
        ;

   return 0;
}

2. 用户堆栈里发生的故事

2.1 �~�译�q�行该程�?�q�设�|�断点在sig_int函数开�?0x80482e8)�Q��ƈ讄��SIGINT信号的处理方�?br />hex@Gentoo ~/signal $ gdb ./sigint
(gdb) b *0x80482e8
Breakpoint 1 at 0x80482e8: file sigint.c, line 6.
(gdb) handle SIGINT noprint pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal        Stop   Print   Pass to program   Description
SIGINT        No   No   Yes       Interrupt
(gdb) r
Starting program: /home/gj/signal/sigint

2.2 向该�E�序发送信�? kill -INT 此程序的pid�?br />hex@Gentoo ~/signal $ kill -INT 4639

2.3 该程序收��C��号后停在断点�?br />Breakpoint 1, sig_int (signo=2) at sigint.c:6
6   {
(gdb) i r esp
esp            0xbfffe7ec   0xbfffe7ec
(gdb) x/40a 0xbfffe7ec
0xbfffe7ec:   0xb7fff400   0x2   0x33   0x0
0xbfffe7fc:   0x7b   0x7b   0x8048930 <__libc_csu_init>   0x80488f0 <__libc_csu_fini>
0xbfffe80c:   0xbfffed58   0xbfffed40   0x0   0x0
0xbfffe81c:   0xbfffec18   0x0   0x0   0x0
0xbfffe82c:   0x8048336    0x73   0x213   0xbfffed40
0xbfffe83c:   0x7b   0xbfffead0   0x0   0x0
0xbfffe84c:   0x0   0x0   0x0   0x0
0xbfffe85c:   0x0   0x0   0x0   0x0
0xbfffe86c:   0x0   0x0   0x0   0x0
0xbfffe87c:   0x0   0x0   0x0   0x0
栈上的内容�ؓ信号栈sigframe�Q?br />�Ҏ��此结构可以知道：
1). �q�回地址0xb7fff400�Q�它指向vdso里的sigreturn
(gdb) x/10i 0xb7fff400
   0xb7fff400 <__kernel_sigreturn>:   pop    %eax
   0xb7fff401 <__kernel_sigreturn+1>:   mov    $0x77,%eax
   0xb7fff406 <__kernel_sigreturn+6>:   int    $0x80
�q�个地址�Ҏ��内核的不同而不同，我的内核版本�?.6.38�?br />2). 信号处理�E�序完成后，会回�?eip = 0x8048336 的地址�l�箋执行�?br />

2.4 执行完sig_int函数后，�q�入了__kernel_sigreturn�Q�接着回到了代�?x8048336处，一切恢复了正常�?br />(gdb) x/5i $pc
=> 0x8048336 :   jmp    0x8048336
(gdb) i r esp
esp            0xbfffed40   0xbfffed40

在用户层我们能看到的只有上面�q�么多信息了�Q�可能有一个地方不能理解：在上面过�E�c�?�?xbfffe7ec起那一块栈上的内容从哪来的�Q�（正常情况下堆栈esp应该一直指向在�q�程d中显�C�的esp�?xbfffed40�Q?br />
现在来看看在上面�q�些现象之下�Q�内核的堆栈发生了怎样的变化�?br />
3. 内核堆栈里发生的故事
3.1 发信��h��
�?2.2 里当执行kill -INT 4639后，pid�?639的程序（也就是我们运行的 ./sigint�Q�会收到一个信��P��但是信号实际都是在内栔R��实现的。每个进�E�（�q�里只讲�q�程的情况，�U�程�c�M��Q�线�E�有一个tid�Q�都有一个pid�Q�与此pid对应有一个结�?task_struct �Q�在task_struct里有一个变�?struct sigpending pending�Q�当该进�E�收��C��h��Q��ƈ不会立即作出反应�Q�只是让内核把这个信可��在了此变量里�Q�它里面是一个链表结构）。当�Ӟ��此时与内核堆栈还没有多大关系�?br />
3.2 ��信�?br /> 如果只记录了信号�Q�但没有相应反应�Q�那有什么用啊。一个进�E�在什�?情况下会��信��L��存在呢？�?lt;情景分析>里说��C��Q?#8220;在中断机制中�Q�处理器的硬件在每条指��o�l�束旉��要检��是否有中断��h��的存在。信��h��制是�U��Y件的�Q�当然不能依靠硬件来��信��L��到来。同�Ӟ��要在每条指��o�l�束旉��来检��显然是不现实的�Q�甚��x��不可能的。所以对信号的检��机制是�Q�每当从�pȝ��调用�Q�中断处理或异常处理�q�回到用��L��间的前夕�Q�还有就是当�q�程被从睡眠中唤醒（必定是在�pȝ��调用中）的时候，此时若发现有信号在等待就要提前从�pȝ��调用�q�回。总而言之，不管是正常返回还是提前返回，在返回到用户�I�间的前夕��L��要检��信��L��存在�q�作出反应�?#8221;

因此�Q�对收到的信号做出反应的旉��?从内核返回用��L��间的前夕�Q�那么有那些情况会让�E�序�q�入内核呢？�{�案是中断，异常和系�l�调用。简单了解一下它们发生时内核堆栈的变化�?br />

//-----中断�Q�异常，�pȝ��调用 : 开�?
   1)在用��L��间发生中断时�Q�CPU会自动在内核�I�间保存用户堆栈的SS�Q?用户堆栈的ESP�Q?EFLAGS, 用户�I�间的CS, EIP, 中断�?- 256
   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP | 中断�?�Q?256
   �q�入内核后，会进行一个SAVE_ALL�Q�这样内核栈上的内容为：
   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP | 中断�?�Q?256 | ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX

   好了�Q�一切都处理完时�Q�内核jmp到RESTORE_ALL�Q�它是一个宏�Q�例�Q�在x86_32体系�l�构下，/usr/src/kernel/arch/286/kernel/entry_32.S文�g里包含该宏的定义�Q?br />
   RESTORE做的工作�Q�从它的代码里就可以看出来了�Q?nbsp;
   首先把栈上的 ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX pop到对应的寄存器里
   然后��esp �Q?4 �?“中断�?�Q?256” pop�?
   此时内核栈上的内容�ؓ�Q?br />   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP
   最后执行iret指��o�Q�此时CPU会从内核栈上取出SS, ESP, ELFGAS, CS, EIP�Q�然后接着�q�行�?br />
   2) 在用��L��间发生异常时�Q�CPU自动保存在内核栈的内容�ؓ�Q?br />   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP | 出错代码 error_code
   �Q�注�Q�CPU只是在进入异常时才知道是否应该把出错代码压入堆栈�Q��ؓ什�?�Q�，而从异常处理通过iret指��o�q�回时已�l�时�q�境�q�，CPU已经无从知当初发生异常的原因�Q�因此不会自动蟩�q�这一��，而要靠相应的异常处程序对堆栈加以调整�Q��得在CPU开始执行iret指��o时堆栈顶部是�q�回地址�Q?br />
   �q�入内核后，没有�q�行SAVE_ALL�Q�而是�q�入相应的异常处理函敎ͼ��q�个函数是包装后的，真正的处理函数在后面�Q�（在此函数里会把真正的处理函数的地址push到栈上）�Q�然后jmp到各�U�异常处理所��q��的程序入口error_code�Q�它会像SAVE_ALL那样保存相应的寄存器�Q�没有保存ES�Q�，此时内核�I�间上的内容为：
   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP | 出错代码 error_code | 相应异常处理函数入口 | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX
   �Q�注�Q�如果没有出错代码，则此��gؓ0�Q?br />
   最后结束时与中断类��|��RESTORE_ALL�Q��?br />
   3) 发生�pȝ��调用�Ӟ��CPU自动保存在内核栈的内容�ؓ:
   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP
   ��Z��与中断和异常的栈一��_��在进入系�l�调用入口（ENTRY(system_call)�Q�后会首先push %eax�Q�然后进行SAVE_ALL�Q�此时内核栈上的内容�?br />   | 用户堆栈的SS | 用户堆栈的ESP | EFLAGS | 用户�I�间的CS | EIP | EAX | ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX

   最后结束时与中断类��|��RESTORE_ALL�Q��?br />   //-----中断�Q�异常，�pȝ��调用 : �l�束

中断�Q�异常，�pȝ��调用�q�部分有一炚w��漏的地方�Q�检��信��L��时机��是紧挨着RESTORE_ALL之前发生的�?br />
3.3 �Ҏ��到的信号做出反�?br /> 如果��到有要处理的信��h��Q�就要开始做一些准备工作了�Q�此时内栔R��的内容�ؓ�Q�进入内核现场时的内容）
| 用户堆栈的SS1 | 用户堆栈的ESP1 | EFLAGS1 | 用户�I�间的CS1 | EIP1 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1
�Q�注�Q�？的值有三个选择�Q�中断号 �Q?256�Q�出错代�?error_code�Q�出错代�?error_code�Q?
假设��要处理的信号对应的信号处理�E�序是用戯��p��|�的�Q�即本文中SIGINT对应的信号处理程序sig_int�?br /> 现在要做的事情是让cpu��L��行信号处理程序sig_int�Q�但是执行前需要做好准备工作：
3.3.1 setup_frame
在用��L��间设�|�好信号�?struct sigframe)(假设讄��好栈后esp的��gؓsigframe_esp�Q�在本文中其��gؓ0xbfffe7ec)�Q�即�?.3里看到的栈内宏V�?br /> 注：struct sigframe里至��包含以下内容：
用户堆栈的SS1�Q?用户堆栈的ESP1�Q?EFLAGS1�Q?用户�I�间的CS1�Q?EIP1�Q?ES1�Q?DS1�Q?EAX1�Q?EBP1�Q?EDI1�Q?ESI1�Q?EDX1�Q?ECX1�Q?EBX1

3.3.2 讄��卛_��q�行的eip的��gؓ信号处理函数sig_int的地址�Q��ؓ0x80482e8�Q�，�q�设�|�用户ESP的��gؓsigframe_esp(�?xbfffe7ec)�Q�这是通过修改内核栈里的EIP和ESP的值实现的�Q�因为在从系�l�调用里iret�Ӟ��会从内核栈里取EIP�Q�ESP�?br /> �q�时内核栈的内核�?
| 用户堆栈的SS1 | 0xbfffe7ec | EFLAGS1 | 用户�I�间的CS1 | 0x80482e8 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1

最后，�q�行RESTORE_ALL�Q�内核栈上的内容为：
| 用户堆栈的SS1 | 0xbfffe7ec | EFLAGS1 | 用户�I�间的CS1 | 0x80482e8

RESTORE_ALL里执行完iret后，寄存器内容�ؓ�Q?EIP�?x80482e8(即sig_int),esp�?xbfffe7ec �?于是用户�I�间��C��步骤 2.3

3.4 信号处理�E�序完成以后
2.3 -> 2.4�Q�进入了sig_return�pȝ��调用�Q�在sig_return里，内核栈的内容为（每个名字后面加一�?以便与前面的1区分�Q?br /> | 用户堆栈的SS2 | 用户堆栈的ESP2 | EFLAGS2 | 用户�I�间的CS2 | EIP2 | ? | ES2 | DS2 | EAX2 | EBP2 | EDI2 | ESI2 | EDX2 | ECX2 | EBX2
sig_return要做的主要工作就是根据用��h��里sigframe的��g��改内核栈里的内容�Q��内核栈变�?
| 用户堆栈的SS1 | 用户堆栈的ESP1 | EFLAGS1 | 用户�I�间的CS1 | EIP1 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1

��x��内核栈里的内容和�q�行信号处理前一样了。经�q�RESTORE_ALL后，用户堆栈里的内容也和以前一��P��主要指ESP的��g��P��?

"kill -INT 4639" 只是一�D�小插曲。程序从原处开始运行�?/div>

hex108 2011-07-26 18:27 发表评论

linux下的vdso与vsyscall

hex108 — Mon, 22 Nov 2010 13:19:00 GMT

传统的系�l�调用是怎样的？ —�?int 0x80的时�?/strong>

.... �Q�通过寄存器传�? mov $n ,eax �Q�将�pȝ��调用��h��到eax�? int 0x80

sysenter/sysexit的出�?/strong>

        在一个Kernel.org的邮件列表中�Q�有一��邮件讨��Z��“"Intel P6 vs P7 system call performance”�Q�最后得出的�l�论是采用传�l�的int 0x80的系�l�调用浪费了很多旉��Q�具体原因可以看参考资�?�Q�，而sysenter/sysexit可以弥补�q�个�~�点�Q�所以决定在linux内核中用后都替换前者（最�l�在2.6版本的内�怸�才加入了此功能，即采用sysenter/sysexit�Q��?/p>
        在替换之前首先需要知道满��_��下条件的ntel机器才会有sysenter/sysexit指��o对：Family >= 6�Q�Model >= 3�Q�Stepping >= 3

        如何用替换sysenter/sysexit替换以前的int 0x80呢？linux kenerl 需要考虑到这点：有的机器�q�不支持sysenter/sysexit �Q?于是它跟glibc说好了，“你以后调用系�l�调用的时候就从我�l�你的这个地址调用�Q�这个地址指向的内容要么是int 0x80调用方式�Q�要么是sysenter/sysexit调用方式�Q�我会根据机器来选择其中一�?#8221;�Q�kernel与glibc的配合是如此的默契）�Q�这个地址便是vsyscall的首地址�?/p>
         可以��vdso看成一个shared objdect file�Q�这个文件实际上不存在）,内核��其映射到某个地址�I�间�Q�被所有程序所�׃�n。（我觉得这里用��C��一个技术：多个虚拟��面映射到同一个物理页面。即内核把vdso映射到某个物理页面上�Q�然后所有程序都会有一个页表项指向它，以此来共享，�q�样每个�E�序的vdso地址��可以不相同了）

hex108@ubuntu:~/program$ uname -a Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux
hex108@ubuntu:~/program$ sudo sysctl -w kernel.randomize_va_space=0 //�q�个是必��ȝ��Q�否则vdso的地址是随机的(vsyscall的地址也会相应
// 地发�?/span>变化 )�Q?/font>在下面dd的时候就会出现错�?/span>
//dd: reading `/proc/self/mem': Input/output error

kernel.randomize_va_space = 0 hex108@ubuntu:~/program$ cat /proc/self/maps 00110000-0012c000 r-xp 00000000 08:01 260639 /lib/ld-2.12.1.so 0012c000-0012d000 r--p 0001b000 08:01 260639 /lib/ld-2.12.1.so 0012d000-0012e000 rw-p 0001c000 08:01 260639 /lib/ld-2.12.1.so 0012e000-0012f000 r-xp 00000000 00:00 0 [vdso] 0012f000-00286000 r-xp 00000000 08:01 260663 /lib/libc-2.12.1.so 00286000-00287000 ---p 00157000 08:01 260663 /lib/libc-2.12.1.so 00287000-00289000 r--p 00157000 08:01 260663 /lib/libc-2.12.1.so 00289000-0028a000 rw-p 00159000 08:01 260663 /lib/libc-2.12.1.so 0028a000-0028d000 rw-p 00000000 00:00 0 08048000-08051000 r-xp 00000000 08:01 130326 /bin/cat 08051000-08052000 r--p 00008000 08:01 130326 /bin/cat 08052000-08053000 rw-p 00009000 08:01 130326 /bin/cat 08053000-08074000 rw-p 00000000 00:00 0 [heap] b7df0000-b7ff0000 r--p 00000000 08:01 660864 /usr/lib/locale/locale-archive b7ff0000-b7ff1000 rw-p 00000000 00:00 0 b7ffd000-b7ffe000 r--p 002a1000 08:01 660864 /usr/lib/locale/locale-archive b7ffe000-b8000000 rw-p 00000000 00:00 0 bffdf000-c0000000 rw-p 00000000 00:00 0 [stack]

hex108@ubuntu:~/program$ dd if=/proc/self/mem of=gate.so bs=4096 skip=$[0x12e] count=1 dd: `/proc/self/mem': cannot skip to specified offset 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 0.00176447 s, 2.3 MB/s hex108@ubuntu:~/program$ file gate.so gate.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped hex108@ubuntu:~/program$ objdump -d gate.so gate.so: file format elf32-i386 Disassembly of section .text: ffffe400 <__kernel_sigreturn>: ffffe400: 58 pop %eax ffffe401: b8 77 00 00 00 mov $0x77,%eax ffffe406: cd 80 int $0x80 ffffe408: 90 nop ffffe409: 8d 76 00 lea 0x0(%esi),%esi ffffe40c <__kernel_rt_sigreturn>: ffffe40c: b8 ad 00 00 00 mov $0xad,%eax ffffe411: cd 80 int $0x80 ffffe413: 90 nop ffffe414 <__kernel_vsyscall>: ffffe414: cd 80 int $0x80 ffffe416: c3 ret

syscall 才是最后的赢家�Q?/strong>

         x86 64位从AMD引进了syscall指��o�Q�我在x86 64的机器上�Q�看到的�l�果是syscall取代了sysenter/sysexit�Q�所有的�pȝ��调用用的都是syscall�Q�）�Q�但是vdso,vsyscall的机制依旧未变，只是kernel军_��只在遇到以下几个�pȝ��调用gettimeofday,time和getcpu�Q�通过内核里vsyscall.h中enum vsyscall_num的声明看出来�Q�或者在glibc源代码中搜烦“VSYSCALL_ADDR_”(

#define VSYSCALL_ADDR_vgettimeofday    0xffffffffff600000

#define VSYSCALL_ADDR_vtime 0xffffffffff600400

#define VSYSCALL_ADDR_vgetcpu 0xffffffffff600800

)�Q�时才采用vdso机制�Q�间接调用syscall�Q�具体可以参看资�?�Q�，其他�pȝ��调用直接用指令syscall�Q�原因是�Q?/p>

         "快速系�l�调用指�?比�v中断指��o来说�Q�其消耗时间必然会��一些，但是随着 CPU 设计的发展，��来应该不会再出现类�?Intel Pentium4 �q�样悬殊的差距。�?快速系�l�调用指�?比�v中断方式的系�l�调用方式，�q�存在一定局限，例如无法在一个系�l�调用处理过�E�中再通过"快速系�l�调用指�?调用别的�pȝ��调用。因此，�q�不一定每个系�l�调用都需要通过"快速系�l�调用指�?来实现。比如，对于复杂的系�l�调用例�?fork�Q�两�U�系�l�调用方式的旉��差和�pȝ��调用本��n�q�行消耗的旉��来比�Q�可以忽略不计，此处采取"快速系�l�调用指�?方式没有什么必要。而真正应该��?快速系�l�调用指�?方式的，是那些本�w�运行时间很短，�Ҏ��间精��性要求高的系�l�调用，例如 getuid、gettimeofday �{�等。因此，采取灉|��的手�D�，针对不同的系�l�调用采取不同的方式�Q�才能得到最优化的性能和实现最完美的功能�?nbsp;     ----引自参考资�?



ps:文中的内核版本�ؓ2.6.36�Q�glibc版本�?.11

参考资�?

1. Linux 2.6 �Ҏ��?CPU 快速系�l�调用的支持: http://www.ibm.com/developerworks/cn/linux/kernel/l-k26ncpu/index.html (�q�篇我觉得最�?

2. System Calls �Q?http://www.win.tue.nl/~aeb/linux/lk/lk-4.html�Q�里面有�E�序可以用来搜烦vsyscall�{�的地址�Q�很直接�Q?/p>
3. What is linux-gate.so.1 �Q?http://www.trilithium.com/johan/2005/08/linux-gate/

4. Intel手册�Q�里面有各种资料�Q�手册还是很重要的，也是最基本�?/p>

hex108 2010-11-22 21:19 发表评论