qemu.protocols.execution should not be shutted down for ShannonEMU

[Mem2019]

ShannonEMU also requires breakpoint here.

FirmWire/firmwire/vendor/shannon/machine.py

Line 827 in 490163e

self.set_breakpoint(

If qemu.protocols.execution is stopped, the execution will hang at breakpoint forever. This solves issue #26.

[mariusmue]

Hi,

The protocols are only shut down when going into fuzzing mode for Shannon. This is a conscious design decision for performance, the idea is that one would either:
a) create snapshots after the required breakpoints for boot.
b) Use panda hooks.

However, I can see how this can turn problematic. Possibly you can adjust the pull request to add a --keep-breakpoints-enabled flag which under fuzzing mode does not shutdown the execution protocol.

[Mem2019]

Hi,

The protocols are only shut down when going into fuzzing mode for Shannon. This is a conscious design decision for performance, the idea is that one would either: a) create snapshots after the required breakpoints for boot. b) Use panda hooks.

However, I can see how this can turn problematic. Possibly you can adjust the pull request to add a --keep-breakpoints-enabled flag which under fuzzing mode does not shutdown the execution protocol.

I have tried to fix it in this way. Please take a look. :)

[grant-h]

I don't think this solution will work if breakpoints are expected to work after AFL takes over. When AFL forks, by nature of the fork syscall, all threads except for the calling thread will be shutdown. Since Avatar uses a separate Python thread to read and process GDB events and commands, the breakpoint will never bubble its way back to the caller. But in the case where you are running in fuzzing mode and expect breakpoints to be hit before the forkserver has started, then this solution will work.

Instead of adding another flag to the command line, maybe it would be best to measure if there is any noticeable performance impact of fuzzing with or without this protocol being shutdown. If there isn't an impact, then we can remove the shutdown call entirely. Given that the GDB avatar thread should no longer exist, but the GDB server may still exist, it is unclear what will happen in this case.

[Mem2019]

I don't think this solution will work if breakpoints are expected to work after AFL takes over. When AFL forks, by nature of the fork syscall, all threads except for the calling thread will be shutdown. Since Avatar uses a separate Python thread to read and process GDB events and commands, the breakpoint will never bubble its way back to the caller.

I agree. However, it seems that Avatar2 always works by creating multiple threads, so this problem could be hard to solve if we have to use Avatar2 breakpoint.