operation Iop_And8 received too large an argument
Closed this issue · 1 comments
When trying this scanner on Xen, I've got the 38 instances of the following:
---------------- [ SCANNER ERROR ] ----------------
where: 0xffff82d04020192e started at:0xffff82d040201820
operation Iop_And8 received too large an argument
Traceback (most recent call last):
File "/local/inspectre-gadget.git/analyzer/scanner/scanner.py", line 567, in run
next_states = self.cur_state.step()
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/sim_state.py", line 607, in step
return self.project.factory.successors(self, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/factory.py", line 77, in successors
return self.default_engine.process(*args, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/slicing.py", line 20, in process
return super().process(*args, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/engine.py", line 163, in process
self.process_successors(self.successors, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/failure.py", line 24, in process_successors
return super().process_successors(successors, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/syscall.py", line 26, in process_successors
return super().process_successors(successors, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/hook.py", line 56, in process_successors
return super().process_successors(successors, procedure=procedure, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/unicorn.py", line 389, in process_successors
return super().process_successors(successors, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/soot/engine.py", line 68, in process_successors
return super().process_successors(successors, **kwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/heavy.py", line 174, in process_successors
self.handle_vex_block(irsb)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/super_fastpath.py", line 25, in handle_vex_block
super().handle_vex_block(irsb)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/slicing.py", line 26, in handle_vex_block
super().handle_vex_block(irsb)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/actions.py", line 31, in handle_vex_block
super().handle_vex_block(irsb)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/inspect.py", line 49, in handle_vex_block
super().handle_vex_block(irsb)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 548, in handle_vex_block
self._handle_vex_stmt(stmt)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/slicing.py", line 30, in _handle_vex_stmt
super()._handle_vex_stmt(stmt)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/inspect.py", line 44, in _handle_vex_stmt
super()._handle_vex_stmt(stmt)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/resilience.py", line 39, in inner
return getattr(super(VEXResilienceMixin, self), func)(*iargs, **ikwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/heavy.py", line 245, in _handle_vex_stmt
super()._handle_vex_stmt(stmt)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 52, in _handle_vex_stmt
handler(stmt)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 203, in _handle_vex_stmt_WrTmp
self._perform_vex_stmt_WrTmp(stmt.tmp, self._analyze_vex_stmt_WrTmp_data(stmt.data))
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 200, in _analyze_vex_stmt_WrTmp_data
return self._handle_vex_expr(*a, **kw)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/inspect.py", line 35, in _handle_vex_expr
return super()._handle_vex_expr(expr)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 56, in _handle_vex_expr
result = handler(expr)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 119, in _handle_vex_expr_Binop
return self._handle_vex_expr_Op(expr)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/light.py", line 128, in _handle_vex_expr_Op
return self._perform_vex_expr_Op(expr.op, [self._handle_vex_expr(arg) for arg in expr.args])
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/heavy/actions.py", line 50, in _perform_vex_expr_Op
result = super()._perform_vex_expr_Op(op, exprs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/light/resilience.py", line 39, in inner
return getattr(super(VEXResilienceMixin, self), func)(*iargs, **ikwargs)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/claripy/datalayer.py", line 125, in _perform_vex_expr_Op
return simop.calculate(*args)
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/claripy/irop.py", line 430, in calculate
return self.extend_size(self._calculate(args))
File "/local/inspectre-gadget.git/.venv/lib/python3.9/site-packages/angr/engines/vex/claripy/irop.py", line 483, in _op_mapped
raise SimOperationError("operation %s received too large an argument" % self.name)
angr.errors.SimOperationError: operation Iop_And8 received too large an argument
The start and operation addresses are from:
ffff82d040201820 <common_interrupt>: // <--- start
ffff82d040201820: 0f 1f 00 nopl (%rax)
ffff82d040201823: 48 83 c4 88 add $0xffffffffffffff88,%rsp
ffff82d040201827: fc cld
ffff82d040201828: 48 89 7c 24 70 mov %rdi,0x70(%rsp)
ffff82d04020182d: 31 ff xor %edi,%edi
ffff82d04020182f: 48 89 74 24 68 mov %rsi,0x68(%rsp)
ffff82d040201834: 31 f6 xor %esi,%esi
ffff82d040201836: 48 89 54 24 60 mov %rdx,0x60(%rsp)
ffff82d04020183b: 31 d2 xor %edx,%edx
ffff82d04020183d: 48 89 4c 24 58 mov %rcx,0x58(%rsp)
ffff82d040201842: 31 c9 xor %ecx,%ecx
ffff82d040201844: 48 89 44 24 50 mov %rax,0x50(%rsp)
ffff82d040201849: 31 c0 xor %eax,%eax
ffff82d04020184b: 4c 89 44 24 48 mov %r8,0x48(%rsp)
ffff82d040201850: 4c 89 4c 24 40 mov %r9,0x40(%rsp)
ffff82d040201855: 4c 89 54 24 38 mov %r10,0x38(%rsp)
ffff82d04020185a: 4c 89 5c 24 30 mov %r11,0x30(%rsp)
ffff82d04020185f: 45 31 c0 xor %r8d,%r8d
ffff82d040201862: 45 31 c9 xor %r9d,%r9d
ffff82d040201865: 45 31 d2 xor %r10d,%r10d
ffff82d040201868: 45 31 db xor %r11d,%r11d
ffff82d04020186b: 48 89 5c 24 28 mov %rbx,0x28(%rsp)
ffff82d040201870: 31 db xor %ebx,%ebx
ffff82d040201872: 48 89 6c 24 20 mov %rbp,0x20(%rsp)
ffff82d040201877: 48 8d 6c 24 20 lea 0x20(%rsp),%rbp
ffff82d04020187c: 48 f7 d5 not %rbp
ffff82d04020187f: 4c 89 64 24 18 mov %r12,0x18(%rsp)
ffff82d040201884: 4c 89 6c 24 10 mov %r13,0x10(%rsp)
ffff82d040201889: 4c 89 74 24 08 mov %r14,0x8(%rsp)
ffff82d04020188e: 4c 89 3c 24 mov %r15,(%rsp)
ffff82d040201892: 45 31 e4 xor %r12d,%r12d
ffff82d040201895: 45 31 ed xor %r13d,%r13d
ffff82d040201898: 45 31 f6 xor %r14d,%r14d
ffff82d04020189b: 45 31 ff xor %r15d,%r15d
ffff82d04020189e: 49 c7 c6 ff 7f 00 00 mov $0x7fff,%r14
ffff82d0402018a5: 49 09 e6 or %rsp,%r14
ffff82d0402018a8: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018af: 00 00
ffff82d0402018b1: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018b8: 00 00
ffff82d0402018ba: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018c1: 00 00
ffff82d0402018c3: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
ffff82d0402018ca: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018d1: 00 00
ffff82d0402018d3: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018da: 00 00
ffff82d0402018dc: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018e3: 00 00
ffff82d0402018e5: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018ec: 00 00
ffff82d0402018ee: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018f5: 00 00
ffff82d0402018f7: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
ffff82d0402018fd: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d040201904: 00 00
ffff82d040201906: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d04020190d: 00 00
ffff82d04020190f: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffff82d040201916: 00 00
ffff82d040201918: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
ffff82d04020191e: 49 8b 4e e1 mov -0x1f(%r14),%rcx
ffff82d040201922: 41 8a 5e f9 mov -0x7(%r14),%bl
ffff82d040201926: 49 89 cf mov %rcx,%r15
ffff82d040201929: 48 85 c9 test %rcx,%rcx
ffff82d04020192c: 74 1c je ffff82d04020194a <common_interrupt+0x12a>
ffff82d04020192e: 41 c6 46 f9 00 movb $0x0,-0x7(%r14) // <--- operation
ffff82d040201933: 0f 22 d9 mov %rcx,%cr3
ffff82d040201936: 4d 89 66 e1 mov %r12,-0x1f(%r14)
ffff82d04020193a: f6 84 24 88 00 00 00 testb $0x3,0x88(%rsp)
ffff82d040201941: 03
ffff82d040201942: 4d 0f 45 fc cmovne %r12,%r15
ffff82d040201946: 41 0f 45 dc cmovne %r12d,%ebx
ffff82d04020194a: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
ffff82d04020194f: 48 89 e7 mov %rsp,%rdi
Singled out, that's:
ffff82d04020192e: 41 c6 46 f9 00 movb $0x0,-0x7(%r14) // <--- operation
so I'm confused as to why angr thinks it is an Iop_And8
instruction.
Here are all the files to reproduce:
xen-syms.gz
addr-list.csv
xen-syms is the the finally linked object with all debugging symbols before we package it up to be bootable. One thing that angr
asked for was passing --base 0xffff82d040200000
which it couldn't seem to extract from the ELF headers. Everything else is per the default docs.
Hi Andrew,
Thanks for opening the issue and the files to reproduce it, which helped a lot in debugging the issue.
Although the debug trace outputs where: 0xffff82d04020192e
, the instruction that triggered the bug is at 0xffff82d04020193a
. We output the basic block address because Angr processes (steps) with one block at a time, so we only know at which block the error occurred. I will add extra info to the output to make it clear that is the error occurred somewhere in the basic block.
The instruction that triggers the bug is as follows, so that also explain why it consists of a Iop_And8
instruction:
ffff82d04020193a: f6 84 24 88 00 00 00 testb $0x3,0x88(%rsp)
It is actually a bug in our tool. There was a off-by-one error in our memory model which resulted in a too large size for one operand. I will push a fix.
Thanks again!