Incorrect Resolution of Indirect Calls

[l-kent]

Currently most indirect calls that occur in the main program body (so, not boilerplate initialisation etc. code) are resolved incorrectly or not resolved at all: in /examples:

• arrays/arrays: call R0 at statement 00000662 is resolved to be either stck_chk_guard() or stack_chk_fail(), when it can only be __stack_chk_fail
• arrays_simple/arrays_simple: call R0 at statement 00000607 is resolved to be either stck_chk_guard() or stack_chk_fail(), when it can only be __stack_chk_fail()
• function_got/function_got: call R0 at statement 000003ed is resolved to be a "call" to the global variable x, when is actually a call to the function get_two()
• functionpointer/functionpointer: call R0 at statement 000004f3 is unresolved, when it could be to set_seven(), set_six(), or set_two()
• functionpointer/functionpointer_clang: call R8 at statement 000004fd is unresolved, when it could be to set_seven(), set_six, or set_two
• jumptable/jumptable: call R0 at statements:
  • 00000595 is resolved to be a call to main() or the unidentified address 69640/0x11008, when it should be to add_two()
  • 000005a4 is resolved to be a call to main() or the unidentified address 69640/0x11008, when it should be to add_six()
  • 000005b3 is resolved to be a call to main() or the unidentified address 69640/0x11008, when it should be to sub_seven()
  • 00000789 is resolved to be a call to main(), the unidentified address 69640/0x11008, or stack_chk_fail(), when it can only be stack_chk_fail()
• jumptable/jumptable_clang: call R8 is unresolved at statements
  • 000004e1 - which should be add_two()
  • 000004f0 - which should be add_six()
  • 000004ff - which should be sub_seven()
• jumptable2/jumptable2_clang: call R8 at statements:
  • 000004d0 is resolved to be a "call" to the global variable x when it should be add_two()
  • 000004e6 is resolved to be a "call" to the global variable x when it should be add_six()
  • 000004fc is resolved to be a "call" to the global variable x when it should be sub_seven()
• jumptable2/jumptable2: call R0 is unresolved at statements:
  • 000004f7 - which should be add_two()
  • 00000512 - which should be add_six()
  • 0000052d - which should be sub_seven()
• indirect_call/indirect_call
  • call R1 at statement 000003ad is resolved to be a call to main() when it should be a call to puts()
  • call R0 at statement 000003bc is correctly resolved as a call to greet()

switch2_clang and jumptable3_clang also do not successfully resolve indirect calls, but those examples do not appear to be possible to resolve at present due to an issue with the lifter.

[l-kent]

One part of the issue is that we need to keep track of what is actually being pointed to by a static address, not just the name - is it a function (external or not)? is it a global variable? something else (most likely a section of memory known to contain a pointer to a set location)? Currently no distinction is made between a pointer to some function add() and a pointer to a pointer to add(), for example.

[yousifpatti]

Hi Liam, this is the current progress. I will investigate jump tables next week. (please note you may have issues visualising calls that can be resolved to multiple jumps as there is an issue in the CFG (not related to the analysis).

• arrays/arrays: call R0 at statement 00000662 is resolved to be either stck_chk_guard() or stack_chk_fail(), when it can only be __stack_chk_fail $${\color{red}(FIXED)}$$

• arrays_simple/arrays_simple: call R0 at statement 00000607 is resolved to be either stck_chk_guard() or stack_chk_fail(), when it can only be __stack_chk_fail() $${\color{red}(FIXED)}$$

• function_got/function_got: call R0 at statement 000003ed is resolved to be a "call" to the global variable x, when is actually a call to the function get_two() $${\color{red}(FIXED)}$$

• functionpointer/functionpointer: call R0 at statement 000004f3 is unresolved, when it could be to set_seven(), set_six(), or set_two() $${\color{red}(FIXED)}$$

• functionpointer/functionpointer_clang: call R8 at statement 000004fd is unresolved, when it could be to set_seven(), set_six, or set_two $${\color{red}(FIXED)}$$

• jumptable/jumptable: call R0 at statements:

  • 00000595 is resolved to be a call to main() or the unidentified address 69640/0x11008, when it should be to add_two()
  • 000005a4 is resolved to be a call to main() or the unidentified address 69640/0x11008, when it should be to add_six()
  • 000005b3 is resolved to be a call to main() or the unidentified address 69640/0x11008, when it should be to sub_seven()
  • 00000789 is resolved to be a call to main(), the unidentified address 69640/0x11008, or stack_chk_fail(), when it can only be stack_chk_fail()

• jumptable/jumptable_clang: call R8 is unresolved at statements

  • 000004e1 - which should be add_two()
  • 000004f0 - which should be add_six()
  • 000004ff - which should be sub_seven()

• jumptable2/jumptable2_clang: call R8 at statements:

  • 000004d0 is resolved to be a "call" to the global variable x when it should be add_two()
  • 000004e6 is resolved to be a "call" to the global variable x when it should be add_six()
  • 000004fc is resolved to be a "call" to the global variable x when it should be sub_seven()

• jumptable2/jumptable2: call R0 is unresolved at statements:

  • 000004f7 - which should be add_two()
  • 00000512 - which should be add_six()
  • 0000052d - which should be sub_seven()

• indirect_call/indirect_call

  • call R1 at statement 000003ad is resolved to be a call to main() when it should be a call to puts()
  • call R0 at statement 000003bc is correctly resolved as a call to greet() $${\color{red}(FIXED)}$$

switch2_clang and jumptable3_clang also do not successfully resolve indirect calls, but those examples do not appear to be possible to resolve at present due to an issue with the lifter.

[l-kent]

There are still issues with some examples: jumptable (all variations) - fails to resolve all indirect calls jumptable2 (all variations) - incorrectly resolves all indirect calls to be to the global variable 'jump_table' instead of to the functions that 'jump_table' contains pointers to indirect_call_out_param - fails to resolve all indirect calls

[l-kent]

Current status - the following test cases in test/correct do not resolve indirect calls correctly:

• functionpointer/clang_O2
• functionpointer/gcc_O2
• jumptable/clang
• jumptable/clang_no_plt_no_pic
• jumptable/clang_pic
• jumptable2/clang
• jumptable2/clang_no_plt_no_pic
• jumptable2/clang_pic
• jumptable2/gcc_O2

[l-kent]

I think reverting the solver optimisation has changed this a bit so I'll have to test everything again