On 7/16/24 02:02, Simon Hamelin wrote:
On 7/16/24 01:08, Pierrick Bouvier wrote:
On 7/15/24 01:09, Simon Hamelin wrote:
Hello Pierrick,
Could you share a bit more information on the final goal, if possible?
Is that used for fuzzing binaries, security analysis, or other things?
I'm currently using this plugin for security analysis purposes.
Basically my goal is to simulate fault injection using QEMU. To do so
I'm using this plugin along with another plugin that skips an
instruction at a given address. With this plugin I'm able to see how the
program reacts to the fault and stop it with a custom return code.
Basically there are 4 cases:
- The fault does not disrupt the program and it reaches the expected
address.
- The fault disrupt the program and it reaches an unexpected address
known as the "target" address.
- The fault disrupt the program in such a way that it executes a lot
of instructions without reaching the expected address, this situation is
known as a "timeout".
- The fault crashes the guest, causing it to reach an error handler
address.
Thanks for sharing this, it's an interesting use case.
How did you implement instruction skipping?
Is that based on current API, or do you have a QEMU fork?
I had to extend the current API to support writing guest registers,
specifically I'm skipping instructions by writing to the PC register. To
do this I use the set_pc function of the CPUClass struct. This requires
a bit of a hack to make the TCG react to the PC change as it's normal
behavior is to execute the entire TB and ignore the PC change. To make
the TCG react to this modification the only way I've found is to leave
it midway it's execution using the `cpu_loop_exit` function.
Ok.
So far, our API is designed to not allow modification on guest side
(code or data wise). It's definitely a discussion we should start at
some point, as it may be needed for specific use cases.
Thanks!
