Unable to identify BB 0x80002a0 in uEmu.3Dprinter

[B03901108]

Hi, I encountered an issue when running Fuzzware on uEmu.3Dprinter. Fuzzware seems unable to list BB 0x80002a0 in the BB trace/set of a test case that covers this BB. As a result, Fuzzware never declares the discovery of this BB during fuzzing even if some of the test cases cover this BB. BB 0x80002a0 is in valid_basic_blocks.txt. It also looks legit in the firmware disassembly. Did you come across similar issues before? Thank you.

Here are some details of the issue. I ran Fuzzware (commit d047baf) on an Intel Xeon E5-2683 v4 server (Ubuntu 22.04.3 LTS). I ran the unmodified Fuzzware on uEmu.3Dprinter five times, each time 24 hours on four cores. Then, I modified Fuzzware such that native/time.c only counts the BBs in valid_basic_blocks.txt for periodic interrupt firing and an empty code hook is used conditionally. The test harness running with a test case only applies the hook if a specific token exists in the local directory. With the modified native/time.c, the control flow of uEmu.3Dprinter running with a test case should remain the same with or without the code hook.

I ran the modified fuzzware_harness.harness on a high-coverage test case, with and without the code hook. The control flow changed when the harness applied the code hook. After debugging, I noticed that using the code hook led to extra BBs (0x80002a0) in the BB trace. Based on the BB traces with and without the code hook, the test case should cover BB 0x80002a0 anyway. I modified native/time.c again to ignore this BB for periodic interrupt firing. The control flow is then the same with or without the code hook.

So far, the modified Fuzzware (including the harness) works well for other firmware from P2IM and uEmu. Feel free to ask for additional information if that helps.

[Scepticz]

Hi B03901108,

Just to clarify, by a "code hook" you mean a hook which gets executed for each instruction, right?

These types of hooks change the boundaries of translation blocks and thus can change the timings of interrupt triggers. In case you ran the fuzzing without the hooks and the re-runs with hooks enabled, this could explain the difference in control flow.

Best
Tobi

[B03901108]

@Scepticz I am aware of the impacts of a code hook (executed for each instruction) on the IRQ modeling. That is why I have already modified the native/timer.c to only count the BBs in valid_basic_blocks.txt for periodic IRQ firing (My issue also mentioned this).

Even so, I can still observe that the BB trace from the unmodified Fuzzware lacks BB 0x80002a0. The BB trace indicates that the test case must have covered this BB. The Fuzzware I am using is not from the latest commit, so I am curious if this issue is platform-dependent, has been patched, or still exists in the latest Fuzzware.

[Scepticz]

I am not aware of an acute known issue that was fixed in the meantime that I would see as related. There could be different things playing into this. If you run the pipeline with the --full-traces option, then you can later diff your full basic block trace from your replay to the one in the pipeline output. That has been a way for me to look at where the behavior diverged.

[B03901108]

@Scepticz After I modified native/timer.c to not count translation blocks and BB 0x80002a0, the BB traces with and without an empty code hook are identical except for translation blocks and BB 0x80002a0. This is also my ad hoc way to avoid this issue and keep using Fuzzware.

I am currently fine with the above ad hoc solution. Still, this behavior is weird to me, so I consider it helpful to raise an issue. Just to be sure, did you cover this BB in your experiments with uEmu/uEmu.3Dprinter? Thank you.

[B03901108]

@Scepticz Hi, my edit of the previous comment might be too late, so I made the question a new comment. Did Fuzzware cover BB 0x80002a0 in uEmu.3Dprinter during the evaluation? Great thanks for the help.

[Scepticz]

I looked at the coverage for 3Dprinter and the basic block 0x80002a0 was never covered by Fuzzware