* [RFC]confusion about syscall @ 2012-07-15 2:28 王哲 2012-07-15 2:52 ` Peter Teoh 2012-07-15 5:49 ` Mulyadi Santosa 0 siblings, 2 replies; 9+ messages in thread From: 王哲 @ 2012-07-15 2:28 UTC (permalink / raw) To: kernelnewbies Hi all: i write two simple program to invoke syscall getpid. the first program (getpid1.c) is as followed: #include <stdio.h> #include <unistd.h> int main(void) { unsigned long value = 0; __asm__("int $0x80":"=a"(value):"0"(20)); return 0; } and use objdump -d a.out disassembling it : ... 80483c2: b8 14 00 00 00 mov $0x14,%eax 80483c7: 89 c3 mov %eax,%ebx 80483c9: 89 d8 mov %ebx,%eax 80483cb: cd 80 int $0x80 ... and the second program: #include <stdio.h> #include <unistd.h> int main(void) { unsigned long value = 0; value = getpid(); return 0; } and disassembling it:( objdump -d a.out) ... 08048300 <getpid@plt>: 8048300: ff 25 00 a0 04 08 jmp *0x804a000 8048306: 68 00 00 00 00 push $0x0 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> ... 080483e4 <main>: 80483e4: 55 push %ebp 80483e5: 89 e5 mov %esp,%ebp 80483e7: 83 e4 f0 and $0xfffffff0,%esp 80483ea: 83 ec 10 sub $0x10,%esp 80483ed: c7 44 24 0c 00 00 00 movl $0x0,0xc(%esp) 80483f4: 00 80483f5: e8 06 ff ff ff call 8048300 <getpid@plt> 80483fa: 89 44 24 0c mov %eax,0xc(%esp) 80483fe: b8 00 00 00 00 mov $0x0,%eax ... question: why i can't find the "movl $0x14,%eax" "int 0x80" in the second program after disassembling? any advice will be help! thanks in advance! wanny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/d249e4c1/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 2:28 [RFC]confusion about syscall 王哲 @ 2012-07-15 2:52 ` Peter Teoh 2012-07-15 5:49 ` Mulyadi Santosa 1 sibling, 0 replies; 9+ messages in thread From: Peter Teoh @ 2012-07-15 2:52 UTC (permalink / raw) To: kernelnewbies int 80, i think, is hardly used nowadays: http://wiki.osdev.org/System_Calls http://articles.manugarg.com/systemcallinlinux2_6.html http://semipublic.comp-arch.net/wiki/SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET and even for SYSENTER instruction, it will not be compiled into your program, but exists inside some external libraries, unless u compile it as static. On Sun, Jul 15, 2012 at 10:28 AM, ?? <wangzhe5004@gmail.com> wrote: > Hi all: > > i write two simple program to invoke syscall getpid. > > the first program (getpid1.c) is as followed: > #include <stdio.h> > #include <unistd.h> > > int main(void) > { > unsigned long value = 0; > __asm__("int $0x80":"=a"(value):"0"(20)); > return 0; > } > > and use objdump -d a.out disassembling it : > ... > 80483c2: b8 14 00 00 00 mov $0x14,%eax > 80483c7: 89 c3 mov %eax,%ebx > 80483c9: 89 d8 mov %ebx,%eax > 80483cb: cd 80 int $0x80 > ... > > > and the second program: > > #include <stdio.h> > #include <unistd.h> > > int main(void) > { > unsigned long value = 0; > value = getpid(); > return 0; > } > > and disassembling it:( objdump -d a.out) > ... > 08048300 <getpid@plt>: > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 > 8048306: 68 00 00 00 00 push $0x0 > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> > ... > 080483e4 <main>: > 80483e4: 55 push %ebp > 80483e5: 89 e5 mov %esp,%ebp > 80483e7: 83 e4 f0 and $0xfffffff0,%esp > 80483ea: 83 ec 10 sub $0x10,%esp > 80483ed: c7 44 24 0c 00 00 00 movl $0x0,0xc(%esp) > 80483f4: 00 > 80483f5: e8 06 ff ff ff call 8048300 > <getpid@plt> > 80483fa: 89 44 24 0c mov %eax,0xc(%esp) > 80483fe: b8 00 00 00 00 mov $0x0,%eax > ... > > question: > why i can't find the "movl $0x14,%eax" "int 0x80" in the second > program after disassembling? > > any advice will be help! > thanks in advance! > wanny > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/bd76014e/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 2:28 [RFC]confusion about syscall 王哲 2012-07-15 2:52 ` Peter Teoh @ 2012-07-15 5:49 ` Mulyadi Santosa 2012-07-15 9:18 ` 王哲 2012-07-15 10:46 ` Peter Teoh 1 sibling, 2 replies; 9+ messages in thread From: Mulyadi Santosa @ 2012-07-15 5:49 UTC (permalink / raw) To: kernelnewbies Hi... On Sun, Jul 15, 2012 at 9:28 AM, ?? <wangzhe5004@gmail.com> wrote: > and the second program: > > #include <stdio.h> > #include <unistd.h> > > int main(void) > { > unsigned long value = 0; > value = getpid(); > return 0; > } > > and disassembling it:( objdump -d a.out) > ... > 08048300 <getpid@plt>: > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 > 8048306: 68 00 00 00 00 push $0x0 > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> Looks like jumping into vsyscall page to me... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 5:49 ` Mulyadi Santosa @ 2012-07-15 9:18 ` 王哲 2012-07-15 17:42 ` Mulyadi Santosa 2012-07-15 10:46 ` Peter Teoh 1 sibling, 1 reply; 9+ messages in thread From: 王哲 @ 2012-07-15 9:18 UTC (permalink / raw) To: kernelnewbies 2012/7/15 Mulyadi Santosa <mulyadi.santosa@gmail.com> > Hi... > > On Sun, Jul 15, 2012 at 9:28 AM, ?? <wangzhe5004@gmail.com> wrote: > > and the second program: > > > > #include <stdio.h> > > #include <unistd.h> > > > > int main(void) > > { > > unsigned long value = 0; > > value = getpid(); > > return 0; > > } > > > > and disassembling it:( objdump -d a.out) > > ... > > 08048300 <getpid@plt>: > > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 > > 8048306: 68 00 00 00 00 push $0x0 > > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> > > Looks like jumping into vsyscall page to me... > thanks for reply. and i wander why the address of vsyscall page is not 0xffffe000 in my system? ... b7806000-b7807000 r-xp 00000000 00:00 0 [vdso] b7807000-b7827000 r-xp 00000000 08:08 2491275 /lib/i386-linux-gnu/ ld-2.15.so b7827000-b7828000 r--p 0001f000 08:08 2491275 /lib/i386-linux-gnu/ ld-2.15.so b7828000-b7829000 rw-p 00020000 08:08 2491275 /lib/i386-linux-gnu/ ld-2.15.so ... root at glinuxi-G31M-ES2C:~# ldd /bin/ls linux-gate.so.1 => (0xb786b000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb7839000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb7830000) libacl.so.1 => /lib/i386-linux-gnu/libacl.so.1 (0xb7826000) ... > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/d64166b7/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 9:18 ` 王哲 @ 2012-07-15 17:42 ` Mulyadi Santosa 0 siblings, 0 replies; 9+ messages in thread From: Mulyadi Santosa @ 2012-07-15 17:42 UTC (permalink / raw) To: kernelnewbies Hi... On Sun, Jul 15, 2012 at 4:18 PM, ?? <wangzhe5004@gmail.com> wrote: > thanks for reply. > and i wander why the address of vsyscall page is not 0xffffe000 in my > system? address space randomization sometimes put the vsyscall page in much lower address AFAIK. And it varies per invocation... But wait, i just recall that your getpid() might contain a jump into unpatched PLT first. It happens for the first time an external function is called. On subsequent call, getpid() will jump directly to the needed address in glibc. Once I wrote about it....try google... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 5:49 ` Mulyadi Santosa 2012-07-15 9:18 ` 王哲 @ 2012-07-15 10:46 ` Peter Teoh 2012-07-15 12:36 ` 王哲 1 sibling, 1 reply; 9+ messages in thread From: Peter Teoh @ 2012-07-15 10:46 UTC (permalink / raw) To: kernelnewbies Hi Mulyadi and WangZhe, Nice to write to you again....:-). On Sun, Jul 15, 2012 at 1:49 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote: > Hi... > > On Sun, Jul 15, 2012 at 9:28 AM, ?? <wangzhe5004@gmail.com> wrote: > > and the second program: > > > > #include <stdio.h> > > #include <unistd.h> > > > > int main(void) > > { > > unsigned long value = 0; > > value = getpid(); > > return 0; > > } > > > > and disassembling it:( objdump -d a.out) > > ... > > 08048300 <getpid@plt>: > > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 > > 8048306: 68 00 00 00 00 push $0x0 > > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> > > Looks like jumping into vsyscall page to me... > > after I start the process, and doing a gdb -p <pid>: (gdb) disassemble main Dump of assembler code for function main: 0x0000000000400564 <+0>: push %rbp 0x0000000000400565 <+1>: mov %rsp,%rbp 0x0000000000400568 <+4>: sub $0x10,%rsp 0x000000000040056c <+8>: movq $0x0,-0x8(%rbp) 0x0000000000400574 <+16>: mov $0x0,%eax 0x0000000000400579 <+21>: callq 0x400460 <getpid@plt> 0x000000000040057e <+26>: cltq 0x0000000000400580 <+28>: mov %rax,-0x8(%rbp) 0x0000000000400584 <+32>: movabs $0x9184e72a000,%rdi 0x000000000040058e <+42>: mov $0x0,%eax 0x0000000000400593 <+47>: callq 0x400470 <sleep@plt> 0x0000000000400598 <+52>: mov $0x0,%eax 0x000000000040059d <+57>: leaveq 0x000000000040059e <+58>: retq End of assembler dump. (gdb) disassemble getpid Dump of assembler code for function getpid: 0x00007f19ae558530 <+0>: mov %fs:0x2d4,%edx 0x00007f19ae558538 <+8>: cmp $0x0,%edx 0x00007f19ae55853b <+11>: jle 0x7f19ae558540 <getpid+16> 0x00007f19ae55853d <+13>: mov %edx,%eax 0x00007f19ae55853f <+15>: retq 0x00007f19ae558540 <+16>: jne 0x7f19ae558554 <getpid+36> 0x00007f19ae558542 <+18>: mov %fs:0x2d0,%eax 0x00007f19ae55854a <+26>: test %eax,%eax 0x00007f19ae55854c <+28>: nopl 0x0(%rax) 0x00007f19ae558550 <+32>: je 0x7f19ae558554 <getpid+36> 0x00007f19ae558552 <+34>: repz retq 0x00007f19ae558554 <+36>: mov $0x27,%eax 0x00007f19ae558559 <+41>: syscall 0x00007f19ae55855b <+43>: test %edx,%edx 0x7f19ae55855d <getpid+45>: jne 0x7f19ae558552 <getpid+34> 0x7f19ae55855f <getpid+47>: mov %eax,%fs:0x2d0 0x7f19ae558567 <getpid+55>: retq And to check the address space: (gdb) info sharedlibrary >From To Syms Read Shared Object Library 0x00007f19ae4cb8c0 0x00007f19ae5dec60 Yes (*) /lib/libc.so.6 0x00007f19ae830af0 0x00007f19ae849704 Yes (*) /lib64/ld-linux-x86-64.so.2 (*): Shared library is missing debugging information. and if u want: cat /proc/2282/maps 7f19ae82a000-7f19ae82b000 rw-p 0017d000 08:05 9922 /lib/libc-2.11.1.so 7f19ae830000-7f19ae850000 r-xp 00000000 08:05 8824 /lib/ld-2.11.1.so 7ffff2031000-7ffff2052000 rw-p 00000000 00:00 0 [stack] 7ffff21af000-7ffff21b0000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] noticed also that static analysis tools like "objdump -d" is generally avoided, if u want to understand dynamic addresses. From above, we can conclude that the "sysenter" (this is intel syntax, or "syscall", in AMD syntax as used by gdb disassembly above) is used for the transition to the kernel - as embedded inside the libc.so.6. > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/a154aab0/attachment-0001.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 10:46 ` Peter Teoh @ 2012-07-15 12:36 ` 王哲 2012-07-15 15:24 ` Peter Teoh 0 siblings, 1 reply; 9+ messages in thread From: 王哲 @ 2012-07-15 12:36 UTC (permalink / raw) To: kernelnewbies 2012/7/15 Peter Teoh <htmldeveloper@gmail.com> > Hi Mulyadi and WangZhe, > > Nice to write to you again....:-). > > On Sun, Jul 15, 2012 at 1:49 PM, Mulyadi Santosa < > mulyadi.santosa at gmail.com> wrote: > >> Hi... >> >> On Sun, Jul 15, 2012 at 9:28 AM, ?? <wangzhe5004@gmail.com> wrote: >> > and the second program: >> > >> > #include <stdio.h> >> > #include <unistd.h> >> > >> > int main(void) >> > { >> > unsigned long value = 0; >> > value = getpid(); >> > return 0; >> > } >> > >> > and disassembling it:( objdump -d a.out) >> > ... >> > 08048300 <getpid@plt>: >> > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 >> > 8048306: 68 00 00 00 00 push $0x0 >> > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> >> >> Looks like jumping into vsyscall page to me... >> >> > after I start the process, and doing a gdb -p <pid>: > > (gdb) disassemble main > Dump of assembler code for function main: > 0x0000000000400564 <+0>: push %rbp > 0x0000000000400565 <+1>: mov %rsp,%rbp > 0x0000000000400568 <+4>: sub $0x10,%rsp > 0x000000000040056c <+8>: movq $0x0,-0x8(%rbp) > 0x0000000000400574 <+16>: mov $0x0,%eax > 0x0000000000400579 <+21>: callq 0x400460 <getpid@plt> > 0x000000000040057e <+26>: cltq > 0x0000000000400580 <+28>: mov %rax,-0x8(%rbp) > 0x0000000000400584 <+32>: movabs $0x9184e72a000,%rdi > 0x000000000040058e <+42>: mov $0x0,%eax > 0x0000000000400593 <+47>: callq 0x400470 <sleep@plt> > 0x0000000000400598 <+52>: mov $0x0,%eax > 0x000000000040059d <+57>: leaveq > 0x000000000040059e <+58>: retq > End of assembler dump. > (gdb) disassemble getpid > Dump of assembler code for function getpid: > 0x00007f19ae558530 <+0>: mov %fs:0x2d4,%edx > 0x00007f19ae558538 <+8>: cmp $0x0,%edx > 0x00007f19ae55853b <+11>: jle 0x7f19ae558540 <getpid+16> > 0x00007f19ae55853d <+13>: mov %edx,%eax > 0x00007f19ae55853f <+15>: retq > 0x00007f19ae558540 <+16>: jne 0x7f19ae558554 <getpid+36> > 0x00007f19ae558542 <+18>: mov %fs:0x2d0,%eax > 0x00007f19ae55854a <+26>: test %eax,%eax > 0x00007f19ae55854c <+28>: nopl 0x0(%rax) > 0x00007f19ae558550 <+32>: je 0x7f19ae558554 <getpid+36> > 0x00007f19ae558552 <+34>: repz retq > 0x00007f19ae558554 <+36>: mov $0x27,%eax > 0x00007f19ae558559 <+41>: syscall > 0x00007f19ae55855b <+43>: test %edx,%edx > 0x7f19ae55855d <getpid+45>: jne 0x7f19ae558552 <getpid+34> > 0x7f19ae55855f <getpid+47>: mov %eax,%fs:0x2d0 > 0x7f19ae558567 <getpid+55>: retq > > Hi peter: question1: why your system is "0x00007f19ae558554 <+36>: mov $0x27,%eax", getpid syscall number is 0x14 question2: i use gdb disassemble getpid just like you and the result: (gdb) disassemble getpid Dump of assembler code for function getpid: 0xb7771a40 <+0>: mov %gs:0x6c,%edx 0xb7771a47 <+7>: cmp $0x0,%edx 0xb7771a4a <+10>: jle 0xb7771a50 <getpid+16> 0xb7771a4c <+12>: mov %edx,%eax 0xb7771a4e <+14>: repz ret 0xb7771a50 <+16>: jne 0xb7771a62 <getpid+34> 0xb7771a52 <+18>: mov %gs:0x68,%eax 0xb7771a58 <+24>: test %eax,%eax 0xb7771a5a <+26>: lea 0x0(%esi),%esi 0xb7771a60 <+32>: jne 0xb7771a4e <getpid+14> 0xb7771a62 <+34>: mov $0x14,%eax 0xb7771a67 <+39>: call *%gs:0x10 can you explain the meaning of "call *%gs:0x10"? Thanks! > And to check the address space: > > (gdb) info sharedlibrary > From To Syms Read Shared Object Library > 0x00007f19ae4cb8c0 0x00007f19ae5dec60 Yes (*) /lib/libc.so.6 > 0x00007f19ae830af0 0x00007f19ae849704 Yes (*) > /lib64/ld-linux-x86-64.so.2 > (*): Shared library is missing debugging information. > > > and if u want: > > cat /proc/2282/maps > > 7f19ae82a000-7f19ae82b000 rw-p 0017d000 08:05 9922 > /lib/libc-2.11.1.so > 7f19ae830000-7f19ae850000 r-xp 00000000 08:05 8824 > /lib/ld-2.11.1.so > 7ffff2031000-7ffff2052000 rw-p 00000000 00:00 0 > [stack] > 7ffff21af000-7ffff21b0000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > > noticed also that static analysis tools like "objdump -d" is generally > avoided, if u want to understand dynamic addresses. From above, we can > conclude that the "sysenter" (this is intel syntax, or "syscall", in AMD > syntax as used by gdb disassembly above) is used for the transition to the > kernel - as embedded inside the libc.so.6. > > >> -- >> regards, >> >> Mulyadi Santosa >> Freelance Linux trainer and consultant >> >> blog: the-hydra.blogspot.com >> training: mulyaditraining.blogspot.com >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > > -- > Regards, > Peter Teoh > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/b9105e2b/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 12:36 ` 王哲 @ 2012-07-15 15:24 ` Peter Teoh 2012-07-15 15:33 ` Peter Teoh 0 siblings, 1 reply; 9+ messages in thread From: Peter Teoh @ 2012-07-15 15:24 UTC (permalink / raw) To: kernelnewbies just sharing my analysis, correct me if wrong: On Sun, Jul 15, 2012 at 8:36 PM, ?? <wangzhe5004@gmail.com> wrote: > > > 2012/7/15 Peter Teoh <htmldeveloper@gmail.com> > >> Hi Mulyadi and WangZhe, >> >> Nice to write to you again....:-). >> >> On Sun, Jul 15, 2012 at 1:49 PM, Mulyadi Santosa < >> mulyadi.santosa at gmail.com> wrote: >> >>> Hi... >>> >>> On Sun, Jul 15, 2012 at 9:28 AM, ?? <wangzhe5004@gmail.com> wrote: >>> > and the second program: >>> > >>> > #include <stdio.h> >>> > #include <unistd.h> >>> > >>> > int main(void) >>> > { >>> > unsigned long value = 0; >>> > value = getpid(); >>> > return 0; >>> > } >>> > >>> > and disassembling it:( objdump -d a.out) >>> > ... >>> > 08048300 <getpid@plt>: >>> > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 >>> > 8048306: 68 00 00 00 00 push $0x0 >>> > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> >>> >>> Looks like jumping into vsyscall page to me... >>> >>> >> after I start the process, and doing a gdb -p <pid>: >> >> (gdb) disassemble main >> Dump of assembler code for function main: >> 0x0000000000400564 <+0>: push %rbp >> 0x0000000000400565 <+1>: mov %rsp,%rbp >> 0x0000000000400568 <+4>: sub $0x10,%rsp >> 0x000000000040056c <+8>: movq $0x0,-0x8(%rbp) >> 0x0000000000400574 <+16>: mov $0x0,%eax >> 0x0000000000400579 <+21>: callq 0x400460 <getpid@plt> >> 0x000000000040057e <+26>: cltq >> 0x0000000000400580 <+28>: mov %rax,-0x8(%rbp) >> 0x0000000000400584 <+32>: movabs $0x9184e72a000,%rdi >> 0x000000000040058e <+42>: mov $0x0,%eax >> 0x0000000000400593 <+47>: callq 0x400470 <sleep@plt> >> 0x0000000000400598 <+52>: mov $0x0,%eax >> 0x000000000040059d <+57>: leaveq >> 0x000000000040059e <+58>: retq >> End of assembler dump. >> (gdb) disassemble getpid >> Dump of assembler code for function getpid: >> 0x00007f19ae558530 <+0>: mov %fs:0x2d4,%edx >> 0x00007f19ae558538 <+8>: cmp $0x0,%edx >> 0x00007f19ae55853b <+11>: jle 0x7f19ae558540 <getpid+16> >> 0x00007f19ae55853d <+13>: mov %edx,%eax >> 0x00007f19ae55853f <+15>: retq >> 0x00007f19ae558540 <+16>: jne 0x7f19ae558554 <getpid+36> >> 0x00007f19ae558542 <+18>: mov %fs:0x2d0,%eax >> 0x00007f19ae55854a <+26>: test %eax,%eax >> 0x00007f19ae55854c <+28>: nopl 0x0(%rax) >> 0x00007f19ae558550 <+32>: je 0x7f19ae558554 <getpid+36> >> 0x00007f19ae558552 <+34>: repz retq >> 0x00007f19ae558554 <+36>: mov $0x27,%eax >> 0x00007f19ae558559 <+41>: syscall >> 0x00007f19ae55855b <+43>: test %edx,%edx >> 0x7f19ae55855d <getpid+45>: jne 0x7f19ae558552 <getpid+34> >> 0x7f19ae55855f <getpid+47>: mov %eax,%fs:0x2d0 >> 0x7f19ae558567 <getpid+55>: retq >> >> > Hi peter: > question1: why your system is "0x00007f19ae558554 <+36>: mov > $0x27,%eax", > getpid syscall number is 0x14 > > yes u are right - for 32-bit kernel: In arch/x86/kernel> grep getpid *.S syscall_table_32.S: .long sys_getpid /* 20 */ but my linux kernel is 64-bit. > question2: i use gdb disassemble getpid just like you and the > result: > > > (gdb) disassemble getpid > Dump of assembler code for function getpid: > 0xb7771a40 <+0>: mov %gs:0x6c,%edx > 0xb7771a47 <+7>: cmp $0x0,%edx > 0xb7771a4a <+10>: jle 0xb7771a50 <getpid+16> > 0xb7771a4c <+12>: mov %edx,%eax > 0xb7771a4e <+14>: repz ret > 0xb7771a50 <+16>: jne 0xb7771a62 <getpid+34> > 0xb7771a52 <+18>: mov %gs:0x68,%eax > 0xb7771a58 <+24>: test %eax,%eax > 0xb7771a5a <+26>: lea 0x0(%esi),%esi > 0xb7771a60 <+32>: jne 0xb7771a4e <getpid+14> > 0xb7771a62 <+34>: mov $0x14,%eax > 0xb7771a67 <+39>: call *%gs:0x10 > > See the comment for gs in entry_32.S: /* * User gs save/restore * * %gs is used for userland TLS and kernel only uses it for stack * canary which is required to be at %gs:20 by gcc. Read the comment * at the top of stackprotector.h for more info. * * Local labels 98 and 99 are used. */ #ifdef CONFIG_X86_32_LAZY_GS And inside stackprotector.h, content of which is still beyond my completely understanding at the moment, I copied it here: /* * GCC stack protector support. * * Stack protector works by putting predefined pattern at the start of * the stack frame and verifying that it hasn't been overwritten when * returning from the function. The pattern is called stack canary * and unfortunately gcc requires it to be at a fixed offset from %gs. * On x86_64, the offset is 40 bytes and on x86_32 20 bytes. x86_64 * and x86_32 use segment registers differently and thus handles this * requirement differently. * * On x86_64, %gs is shared by percpu area and stack canary. All * percpu symbols are zero based and %gs points to the base of percpu * area. The first occupant of the percpu area is always * irq_stack_union which contains stack_canary at offset 40. Userland * %gs is always saved and restored on kernel entry and exit using * swapgs, so stack protector doesn't add any complexity there. * * On x86_32, it's slightly more complicated. As in x86_64, %gs is * used for userland TLS. Unfortunately, some processors are much * slower at loading segment registers with different value when * entering and leaving the kernel, so the kernel uses %fs for percpu * area and manages %gs lazily so that %gs is switched only when * necessary, usually during task switch. * * As gcc requires the stack canary at %gs:20, %gs can't be managed * lazily if stack protector is enabled, so the kernel saves and * restores userland %gs on kernel entry and exit. This behavior is * controlled by CONFIG_X86_32_LAZY_GS and accessors are defined in * system.h to hide the details. */ Yes, gs register is valid for userspace TLS and thus is per-process, and for more info: http://www.akkadia.org/drepper/tls.pdf http://www.ibm.com/developerworks/linux/library/l-user-space-apps/index.html http://stackoverflow.com/questions/6021273/how-to-allocate-thread-local-storage (and lots of relevant links besides it). can you explain the meaning of "call *%gs:0x10"? > > Thanks! > > > > >> And to check the address space: >> >> (gdb) info sharedlibrary >> From To Syms Read Shared Object Library >> 0x00007f19ae4cb8c0 0x00007f19ae5dec60 Yes (*) /lib/libc.so.6 >> 0x00007f19ae830af0 0x00007f19ae849704 Yes (*) >> /lib64/ld-linux-x86-64.so.2 >> (*): Shared library is missing debugging information. >> >> >> and if u want: >> >> cat /proc/2282/maps >> >> 7f19ae82a000-7f19ae82b000 rw-p 0017d000 08:05 9922 >> /lib/libc-2.11.1.so >> 7f19ae830000-7f19ae850000 r-xp 00000000 08:05 8824 >> /lib/ld-2.11.1.so >> 7ffff2031000-7ffff2052000 rw-p 00000000 00:00 0 >> [stack] >> 7ffff21af000-7ffff21b0000 r-xp 00000000 00:00 0 >> [vdso] >> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 >> [vsyscall] >> >> noticed also that static analysis tools like "objdump -d" is generally >> avoided, if u want to understand dynamic addresses. From above, we can >> conclude that the "sysenter" (this is intel syntax, or "syscall", in AMD >> syntax as used by gdb disassembly above) is used for the transition to the >> kernel - as embedded inside the libc.so.6. >> >> >>> -- >>> regards, >>> >>> Mulyadi Santosa >>> Freelance Linux trainer and consultant >>> >>> blog: the-hydra.blogspot.com >>> training: mulyaditraining.blogspot.com >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies at kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >> >> >> >> -- >> Regards, >> Peter Teoh >> > > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/0c437dec/attachment-0001.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFC]confusion about syscall 2012-07-15 15:24 ` Peter Teoh @ 2012-07-15 15:33 ` Peter Teoh 0 siblings, 0 replies; 9+ messages in thread From: Peter Teoh @ 2012-07-15 15:33 UTC (permalink / raw) To: kernelnewbies I think this is useful: http://stackoverflow.com/questions/9355097/looking-for-system-calls-implementation-on-linux-kernel On Sun, Jul 15, 2012 at 11:24 PM, Peter Teoh <htmldeveloper@gmail.com>wrote: > just sharing my analysis, correct me if wrong: > > On Sun, Jul 15, 2012 at 8:36 PM, ?? <wangzhe5004@gmail.com> wrote: > >> >> >> 2012/7/15 Peter Teoh <htmldeveloper@gmail.com> >> >>> Hi Mulyadi and WangZhe, >>> >>> Nice to write to you again....:-). >>> >>> On Sun, Jul 15, 2012 at 1:49 PM, Mulyadi Santosa < >>> mulyadi.santosa at gmail.com> wrote: >>> >>>> Hi... >>>> >>>> On Sun, Jul 15, 2012 at 9:28 AM, ?? <wangzhe5004@gmail.com> wrote: >>>> > and the second program: >>>> > >>>> > #include <stdio.h> >>>> > #include <unistd.h> >>>> > >>>> > int main(void) >>>> > { >>>> > unsigned long value = 0; >>>> > value = getpid(); >>>> > return 0; >>>> > } >>>> > >>>> > and disassembling it:( objdump -d a.out) >>>> > ... >>>> > 08048300 <getpid@plt>: >>>> > 8048300: ff 25 00 a0 04 08 jmp *0x804a000 >>>> > 8048306: 68 00 00 00 00 push $0x0 >>>> > 804830b: e9 e0 ff ff ff jmp 80482f0 <_init+0x3c> >>>> >>>> Looks like jumping into vsyscall page to me... >>>> >>>> >>> after I start the process, and doing a gdb -p <pid>: >>> >>> (gdb) disassemble main >>> Dump of assembler code for function main: >>> 0x0000000000400564 <+0>: push %rbp >>> 0x0000000000400565 <+1>: mov %rsp,%rbp >>> 0x0000000000400568 <+4>: sub $0x10,%rsp >>> 0x000000000040056c <+8>: movq $0x0,-0x8(%rbp) >>> 0x0000000000400574 <+16>: mov $0x0,%eax >>> 0x0000000000400579 <+21>: callq 0x400460 <getpid@plt> >>> 0x000000000040057e <+26>: cltq >>> 0x0000000000400580 <+28>: mov %rax,-0x8(%rbp) >>> 0x0000000000400584 <+32>: movabs $0x9184e72a000,%rdi >>> 0x000000000040058e <+42>: mov $0x0,%eax >>> 0x0000000000400593 <+47>: callq 0x400470 <sleep@plt> >>> 0x0000000000400598 <+52>: mov $0x0,%eax >>> 0x000000000040059d <+57>: leaveq >>> 0x000000000040059e <+58>: retq >>> End of assembler dump. >>> (gdb) disassemble getpid >>> Dump of assembler code for function getpid: >>> 0x00007f19ae558530 <+0>: mov %fs:0x2d4,%edx >>> 0x00007f19ae558538 <+8>: cmp $0x0,%edx >>> 0x00007f19ae55853b <+11>: jle 0x7f19ae558540 <getpid+16> >>> 0x00007f19ae55853d <+13>: mov %edx,%eax >>> 0x00007f19ae55853f <+15>: retq >>> 0x00007f19ae558540 <+16>: jne 0x7f19ae558554 <getpid+36> >>> 0x00007f19ae558542 <+18>: mov %fs:0x2d0,%eax >>> 0x00007f19ae55854a <+26>: test %eax,%eax >>> 0x00007f19ae55854c <+28>: nopl 0x0(%rax) >>> 0x00007f19ae558550 <+32>: je 0x7f19ae558554 <getpid+36> >>> 0x00007f19ae558552 <+34>: repz retq >>> 0x00007f19ae558554 <+36>: mov $0x27,%eax >>> 0x00007f19ae558559 <+41>: syscall >>> 0x00007f19ae55855b <+43>: test %edx,%edx >>> 0x7f19ae55855d <getpid+45>: jne 0x7f19ae558552 <getpid+34> >>> 0x7f19ae55855f <getpid+47>: mov %eax,%fs:0x2d0 >>> 0x7f19ae558567 <getpid+55>: retq >>> >>> >> Hi peter: >> question1: why your system is "0x00007f19ae558554 <+36>: mov >> $0x27,%eax", >> getpid syscall number is 0x14 >> >> yes u are right - for 32-bit kernel: > > In arch/x86/kernel> > grep getpid *.S > syscall_table_32.S: .long sys_getpid /* 20 */ > > but my linux kernel is 64-bit. > > > >> question2: i use gdb disassemble getpid just like you and the >> result: >> >> >> (gdb) disassemble getpid >> Dump of assembler code for function getpid: >> 0xb7771a40 <+0>: mov %gs:0x6c,%edx >> 0xb7771a47 <+7>: cmp $0x0,%edx >> 0xb7771a4a <+10>: jle 0xb7771a50 <getpid+16> >> 0xb7771a4c <+12>: mov %edx,%eax >> 0xb7771a4e <+14>: repz ret >> 0xb7771a50 <+16>: jne 0xb7771a62 <getpid+34> >> 0xb7771a52 <+18>: mov %gs:0x68,%eax >> 0xb7771a58 <+24>: test %eax,%eax >> 0xb7771a5a <+26>: lea 0x0(%esi),%esi >> 0xb7771a60 <+32>: jne 0xb7771a4e <getpid+14> >> 0xb7771a62 <+34>: mov $0x14,%eax >> 0xb7771a67 <+39>: call *%gs:0x10 >> >> > > See the comment for gs in entry_32.S: > > /* > * User gs save/restore > * > * %gs is used for userland TLS and kernel only uses it for stack > * canary which is required to be at %gs:20 by gcc. Read the comment > * at the top of stackprotector.h for more info. > * > * Local labels 98 and 99 are used. > */ > #ifdef CONFIG_X86_32_LAZY_GS > > And inside stackprotector.h, content of which is still beyond my > completely understanding at the moment, I copied it here: > > /* > * GCC stack protector support. > * > * Stack protector works by putting predefined pattern at the start of > * the stack frame and verifying that it hasn't been overwritten when > * returning from the function. The pattern is called stack canary > * and unfortunately gcc requires it to be at a fixed offset from %gs. > * On x86_64, the offset is 40 bytes and on x86_32 20 bytes. x86_64 > * and x86_32 use segment registers differently and thus handles this > * requirement differently. > * > * On x86_64, %gs is shared by percpu area and stack canary. All > * percpu symbols are zero based and %gs points to the base of percpu > * area. The first occupant of the percpu area is always > * irq_stack_union which contains stack_canary at offset 40. Userland > * %gs is always saved and restored on kernel entry and exit using > * swapgs, so stack protector doesn't add any complexity there. > * > * On x86_32, it's slightly more complicated. As in x86_64, %gs is > * used for userland TLS. Unfortunately, some processors are much > * slower at loading segment registers with different value when > * entering and leaving the kernel, so the kernel uses %fs for percpu > * area and manages %gs lazily so that %gs is switched only when > * necessary, usually during task switch. > * > * As gcc requires the stack canary at %gs:20, %gs can't be managed > * lazily if stack protector is enabled, so the kernel saves and > * restores userland %gs on kernel entry and exit. This behavior is > * controlled by CONFIG_X86_32_LAZY_GS and accessors are defined in > * system.h to hide the details. > */ > > Yes, gs register is valid for userspace TLS and thus is per-process, and > for more info: > > http://www.akkadia.org/drepper/tls.pdf > > > http://www.ibm.com/developerworks/linux/library/l-user-space-apps/index.html > > > http://stackoverflow.com/questions/6021273/how-to-allocate-thread-local-storage > > (and lots of relevant links besides it). > > > > can you explain the meaning of "call *%gs:0x10"? >> >> Thanks! >> >> >> >> >>> And to check the address space: >>> >>> (gdb) info sharedlibrary >>> From To Syms Read Shared Object Library >>> 0x00007f19ae4cb8c0 0x00007f19ae5dec60 Yes (*) /lib/libc.so.6 >>> 0x00007f19ae830af0 0x00007f19ae849704 Yes (*) >>> /lib64/ld-linux-x86-64.so.2 >>> (*): Shared library is missing debugging information. >>> >>> >>> and if u want: >>> >>> cat /proc/2282/maps >>> >>> 7f19ae82a000-7f19ae82b000 rw-p 0017d000 08:05 9922 >>> /lib/libc-2.11.1.so >>> 7f19ae830000-7f19ae850000 r-xp 00000000 08:05 8824 >>> /lib/ld-2.11.1.so >>> 7ffff2031000-7ffff2052000 rw-p 00000000 00:00 0 >>> [stack] >>> 7ffff21af000-7ffff21b0000 r-xp 00000000 00:00 0 >>> [vdso] >>> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 >>> [vsyscall] >>> >>> noticed also that static analysis tools like "objdump -d" is generally >>> avoided, if u want to understand dynamic addresses. From above, we can >>> conclude that the "sysenter" (this is intel syntax, or "syscall", in AMD >>> syntax as used by gdb disassembly above) is used for the transition to the >>> kernel - as embedded inside the libc.so.6. >>> >>> >>>> -- >>>> regards, >>>> >>>> Mulyadi Santosa >>>> Freelance Linux trainer and consultant >>>> >>>> blog: the-hydra.blogspot.com >>>> training: mulyaditraining.blogspot.com >>>> >>>> _______________________________________________ >>>> Kernelnewbies mailing list >>>> Kernelnewbies at kernelnewbies.org >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>> >>> >>> >>> >>> -- >>> Regards, >>> Peter Teoh >>> >> >> > > > -- > Regards, > Peter Teoh > -- Regards, Peter Teoh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120715/b6343f92/attachment.html ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-07-15 17:42 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-15 2:28 [RFC]confusion about syscall 王哲 2012-07-15 2:52 ` Peter Teoh 2012-07-15 5:49 ` Mulyadi Santosa 2012-07-15 9:18 ` 王哲 2012-07-15 17:42 ` Mulyadi Santosa 2012-07-15 10:46 ` Peter Teoh 2012-07-15 12:36 ` 王哲 2012-07-15 15:24 ` Peter Teoh 2012-07-15 15:33 ` Peter Teoh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.