dis crashes disassembling aes
On my (gcc-built) system, dis is crashing when disassembling /kernel/crypto/amd64/aes, thus:
core '101.dis.4960-1347504528' of 4960: dis /kernel/crypto/amd64/aes 08052ce0 dis_tgt_next_symbol (8066b20, 80692f8, 1000, 0, fed7ca00, 85ad) + 1f 0805459a dis_text_section (8066b20, 80478f8, 80692f8, fee3d135) + 6b 0805308b dis_tgt_section_iter (8066b20, 805452f, 80692f8, 8053d28) + e5 080539f9 dis_file (8047b48, 8047a64, 8054f8f, 8053abf, fef20000, 8047a68) + 126 08053cf0 main (8054d9a, feffb0a4, 8047a58, 80525d3, 2, 8047a64) + 259 080525d3 _start (2, 8047b44, 8047b48, 0, 8047b61, 8047b70) + 83
We get this far:
disassembly for /kernel/crypto/amd64/aes section .text .text() .text: c6 63 63 a5 movb $-0x5b,0x63(%rbx) <0xa5> .text+0x4: c6 63 63 a5 movb $-0x5b,0x63(%rbx) <0xa5> .text+0x8: f8 clc .text+0x9: 7c 7c jl +0x7c <0x1087> .text+0xb: 84 f8 testb %bh,%al .text+0xd: 7c 7c jl +0x7c <0x108b> .text+0xf: 84 ee testb %ch,%dh .text+0x11: 77 77 ja +0x77 <0x108a> .text+0x13: 99 cltd .text+0x14: ee outb (%dx) .text+0x15: 77 77 ja +0x77 <0x108e> .text+0x17: 99 cltd .text+0x18: f6 7b 7b idivb 0x7b(%rbx) .text+0x1b: 8d f6 leal %esi,%esi .text+0x1d: 7b 7b jnp +0x7b <0x109a> .text+0x1f: 8d ff leal %edi,%edi .text+0x21: f2 f2 0d ff f2 f2 repnz orl $0xdf2f2ff,%eax 0d zsh: segmentation fault (core dumped) dis /kernel/crypto/amd64/aes
I can provide an 'aes' module and a core, if required.
Updated by Rich Lowe about 8 years ago
This happens when we disassemble 'enc_tab', which is data rather than text (though is in .text).
It is likely that enc_tab should not be text (because it's not), as well as dis not crashing in this case. I suspect that even with dis fixed, it'll be thrown off by the not-code and not actually be useful without enc_tab being moved to rodata.
Updated by Rich Lowe almost 8 years ago
This is because we attempt to use the symcache to start walking the symtab in the middle, and do so even if we've never looked up a symbol before. That is if there is stuff at the beginning of .text which is not actually a component of a symbol we care about.
This happens to aes, no doubt, because of the nature of enc_tab:
We have an invalid instruction, without a symtab entry, prior to any valid symbol in .text, so when we hit the invalid insn, we try to progress forward to the beginning of the next symbol (which we can guarantee is on an insn boundary), but because we're prior to any valid symbol, dis_tgt_lookup() has never populated dt_symcache.
Updated by Bruce Bendwick over 1 year ago
This may occur after disassembling 'enc_tab', which is data in .txt
Try doing it again by enabling enc_tab without any text. I've done this with other files on https://elearningways.com and it went very well. This was done for an e-learning program on which the client had done wrong coding and had hit invalid insn. I worked on it at the beginning of a few symbols the problem was resolved.