Hello,
Upon a fresh git clone (at commit d815add9, current HEAD) and make, I tried running the example from the readme file:
optiwise run -- /usr/bin/echo hello
This however yields during the analysis phase
[snip]
Info: program exited; processing...
Info: merge blocks
Info: output cfg
Info: exit
Info: Reading disassebly from /dev/fd/4...
Error: Uncaught exception:
/dev/fd/4:2980 error: duplicated instruction in objdump?
Further investigating, the disassembly phase disassembles all of my kernel modules (eg /lib/modules/…-amd64/kernel/kernel/arch/x86/crypto/chacha-x86_64.ko).
Opening optiwise_result/disassemble/result.txt.gz at line 2980 points me to the disassembly of /lib/modules/5.10.0-27-amd64/kernel/net/bridge/br_netfilter.ko, with the following disassembly:
[…]
Disassembly of section .text.unlikely:
0000000000000000 <br_nf_pre_routing.cold>:
br_nf_pre_routing.cold():
0: mov $0x0,%rdi ## ====== LINE 2980 HERE
7: movb $0x1,0x0(%rip) # e <br_nf_pre_routing.cold+0xe>
e: callq 13 <br_nf_pre_routing.cold+0x13>
13: xor %eax,%eax
15: jmpq 1a <.LC3+0xf>
Disassembly of section .init.text:
0000000000000000 <init_module>:
br_netfilter_init():
0: callq 5 <init_module+0x5>
5: push %r12
7: mov $0x0,%rdi
where, indeed, a second instruction for address 0 is disassembled (the first one being at the beginning of the .text section).
Looking around the exception thrown in the Optiwise code (src/analyzer/io.cpp:705 at commit d815add9), it indeed seems that the objdump_result C++ map is indexed by (current_module, addr), not accounting for the possible presence of multiple assembly sections in analyzed ELFs.
This prompts me with two questions.
- Is the analysis of the whole kernel modules required? As I understand, analysis results are cached from one run to the other; thus, the only slowdown would be on the first run. This still looks a bit overkill to me -- but is maybe needed.
- Should those
.text.[…] sections be analyzed, or just skipped?
Hello,
Upon a fresh
git clone(at commitd815add9, current HEAD) andmake, I tried running the example from the readme file:This however yields during the analysis phase
Further investigating, the disassembly phase disassembles all of my kernel modules (eg
/lib/modules/…-amd64/kernel/kernel/arch/x86/crypto/chacha-x86_64.ko).Opening
optiwise_result/disassemble/result.txt.gzat line 2980 points me to the disassembly of/lib/modules/5.10.0-27-amd64/kernel/net/bridge/br_netfilter.ko, with the following disassembly:where, indeed, a second instruction for address
0is disassembled (the first one being at the beginning of the.textsection).Looking around the exception thrown in the Optiwise code (
src/analyzer/io.cpp:705at commitd815add9), it indeed seems that theobjdump_resultC++ map is indexed by(current_module, addr), not accounting for the possible presence of multiple assembly sections in analyzed ELFs.This prompts me with two questions.
.text.[…]sections be analyzed, or just skipped?