How to fuzz devices that use timers?

How to fuzz devices that use timers?

[Philippe Mathieu-Daudé]

Hi,

Some devices use timers (QEMUTimer) to emulate hardware precise timings.
i.e. with a flash device, the guest orders erasing it, the physical
erasure takes some time - let say 200ms - and upon completion a bit is
set in a register, and an interruption is eventually raised.
When not multi-tasking, a guest usually poll the register until bit set.

While fuzzing, a payload schedule triggers an erase, then (if we don't
reset the device) thousands of payloads are tested in vain until the
device is ready to process further requests. It is then hard to
understand the patterns used (in 200ms libFuzzer tried ~5000 I/O
other accesses). Even if we can reproduce the pattern with proper
timings, it is also hard to reproduce.

Since we run the fuzzer with the QTest accelerator, my first idea was to
check for 'if (qtest_enabled())' in the timer code, and directly expire
a timer instead of scheduling it. This way we can test reproducers.
However various tests require/verify precise timing, so this would break
various qtests.

Second idea was to add a fuzzer_enabled() method, and check it. But then
I noticed some devices use timers the other way, they start a timer and
wait an event to happen in a correct amount of time, else the timer kick
and error bit is set (this is the watchdog style). If I modify the
timers to directly expire checking fuzzer_enabled(), then these devices
enter failure mode directly without processing further requests.

So I guess I have to go thru each device and check for fuzzer_enabled()
where appropriate...
Any clever ideas?

Thanks

Phil.

Re: How to fuzz devices that use timers?

[Christophe de Dinechin]

> On 28 May 2020, at 11:26, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> 
> Hi,
> 
> Some devices use timers (QEMUTimer) to emulate hardware precise timings.
> i.e. with a flash device, the guest orders erasing it, the physical
> erasure takes some time - let say 200ms - and upon completion a bit is
> set in a register, and an interruption is eventually raised.
> When not multi-tasking, a guest usually poll the register until bit set.
> 
> While fuzzing, a payload schedule triggers an erase, then (if we don't
> reset the device) thousands of payloads are tested in vain until the
> device is ready to process further requests. It is then hard to
> understand the patterns used (in 200ms libFuzzer tried ~5000 I/O
> other accesses). Even if we can reproduce the pattern with proper
> timings, it is also hard to reproduce.
> 
> Since we run the fuzzer with the QTest accelerator, my first idea was to
> check for 'if (qtest_enabled())' in the timer code, and directly expire
> a timer instead of scheduling it. This way we can test reproducers.
> However various tests require/verify precise timing, so this would break
> various qtests.
> 
> Second idea was to add a fuzzer_enabled() method, and check it. But then
> I noticed some devices use timers the other way, they start a timer and
> wait an event to happen in a correct amount of time, else the timer kick
> and error bit is set (this is the watchdog style). If I modify the
> timers to directly expire checking fuzzer_enabled(), then these devices
> enter failure mode directly without processing further requests.
> 
> So I guess I have to go thru each device and check for fuzzer_enabled()
> where appropriate...
> Any clever ideas?

Would it make sense to introduce the idea of device reservation / exclusivity
in the tests? In other words, if you have an “erase”, then you add some
“qtest_reserve_device(device, timeout, …)” and then modify the payload
scheduling to avoid reserved devices.

If there are less of these cases than general watchdogs, this may be a
win in the end, and also clarify the intent.

> 
> Thanks
> 
> Phil.
> 

Re: How to fuzz devices that use timers?

[Paolo Bonzini]

On 28/05/20 11:52, Christophe de Dinechin wrote:
> 
> Since we run the fuzzer with the QTest accelerator, my first idea was to
> check for 'if (qtest_enabled())' in the timer code, and directly expire
> a timer instead of scheduling it. This way we can test reproducers.
> However various tests require/verify precise timing, so this would break
> various qtests.

There is a clock_step command that advance the QEMU_CLOCK_VIRTUAL clock
to the next deadline.  You just have to insert it into the fuzzing input.

Paolo