Closed WorksButNotTested closed 1 year ago
After discussion, we, should add a post_gen
hook here which is passed the PC and the length of the block. We should not include the block ID since this would require TLS and further can vary from one hook to the next and therefore introduces additional complexity.
@WorksButNotTested this is 100% completed right?
Yeah. Landed it all in here. https://github.com/AFLplusplus/qemu-libafl-bridge/pull/22
If we can provide this information to the callback, then we don't need to determine the block size for ourselves in LibAFL here. Note the following links are from the qemu repository itself rather than the fork from the bridge.
We can see the code for generating the callback in the bridge here.
We can see that
hook->gen
is only passed thepc
. However, if we move the hook function to below the call togen_intermediate_code
, then we will be able to include the size of the input block. This can be observed by following the call chain to where QEMU logs the input blocks when provided the-d in_asm
argument where this value is used to generate the debug output. If we consider the ARM code base (although other architectures should be the same).We can see
gen_intermediate_code
here.We can then see the
translator_loop
here. Note that the translator is setting thetb->size
value which is available to us in the functionsetjmp_gen_code
where we call our hook.Lastly, we can see the code for generating the trace output for
-d in_asm
here. Note theIN:
prefix which tells us this is the input block (e.g. the target code being emulated) rather than the intermediate or host representation of the block. Note here the use of thetb->size
by the expressiondc->base.tb->size
.And the disassembler here. It is using the size parameter as a bound for the loop.