Re: [PATCH v2] plugins/stoptrigger: TCG plugin to stop execution under conditions

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

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!