RE: x86 assembly - linking order query

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: RE: x86 assembly - linking order query

>> >You have not used "ret" instruction in AsmFn2, I guess it will cause
>> >undefined behavior. I think it has nothing to do with how you compile
>> >the code. It works perfectly after adding ret instruction at the end
>> >of AsmFn2. Correct me if I am missing something here.
>>
>>
>> Thanks. That was the problem, I didn't notice that. Sorry for the stupid question.

>Can you explain why the lack of 'ret' in AsmFn2 cause a segfault ? And
>why does this not happen when you pass the C file before the asm to
>GCC?



If we look at the dis-assembly of the binary 'good', we can see that 'AsmFn2' is followed by the function '__libc_csu_fini'.  When the control enters the function AsmFn2, since it doesn't have a 'ret' statement after the 'leave' instruction, it would execute the instructions below it and would reach the point '80483c4:' in the function '__libc_csu_fini' & since it encounters a 'ret' instruction there, it would return as if it is returning from AsmFn2. 


If we look at the instructions below the leave instruction in AsmFn2, we can see that these statements doesn't create any stack corruption or any other access violation.


good - disassembled
--------------------

080483b2 <AsmFn2>:
 80483b2:       55                      push   %ebp
 80483b3:       89 e5                   mov    %esp,%ebp
 80483b5:       c9                      leave
 80483b6:       90                      nop
 80483b7:       90                      nop
 80483b8:       90                      nop
 80483b9:       90                      nop
 80483ba:       90                      nop
 80483bb:       90                      nop
 80483bc:       90                      nop
 80483bd:       90                      nop
 80483be:       90                      nop
 80483bf:       90                      nop

080483c0 <__libc_csu_fini>:
 80483c0:       55                      push   %ebp
 80483c1:       89 e5                   mov    %esp,%ebp
 80483c3:       5d                      pop    %ebp
 80483c4:       c3                      ret
 80483c5:       8d 74 26 00             lea    0x0(%esi,%eiz,1),%esi
 80483c9:       8d bc 27 00 00 00 00    lea    0x0(%edi,%eiz,1),%edi





If we disassemble the binary 'bad', we can see that AsmFn2 is followed by the function Main. As before, once the control enters AsmFn2, since it doesn't have a ret statement, it would execute the instructions below and would enter the function main & that would again call  AsmFn1->AsmFn2->main and this process continues and I think after a point of time, stack corruption happens.


bad - disassembled
------------------

0804839e <AsmFn2>:
 804839e:       55                      push   %ebp
 804839f:       89 e5                   mov    %esp,%ebp
 80483a1:       c9                      leave
 80483a2:       90                      nop
 80483a3:       90                      nop

080483a4 <main>:
 80483a4:       55                      push   %ebp
 80483a5:       89 e5                   mov    %esp,%ebp
 80483a7:       83 e4 f0                and    $0xfffffff0,%esp
 80483aa:       e8 e5 ff ff ff          call   8048394 <AsmFn1>
 80483af:       b8 00 00 00 00          mov    $0x0,%eax
 80483b4:       89 ec                   mov    %ebp,%esp
 80483b6:       5d                      pop    %ebp
 80483b7:       c3                      ret
 80483b8:       90                      nop
 80483b9:       90                      nop



--
Sudheer


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux