We are fuzzing an EDK2 application built under simicsOpenBoardPkg using TSFFS with Simics.
The fuzzing configuration includes:
`@tsffs.exceptions = [3,6,14]`
Exceptions 3, 6, and 14 are treated as solutions. When any of these exceptions occur, the corresponding input seed is saved in the solution directory.
During an active fuzzing session:
A crash was detected.
The crashing input seed was saved in the solution directory.
The fuzzing session was interrupted using Ctrl + C.
Following the official reproduction guide:
https://intel.github.io/tsffs/tutorials/edk2-uefi/reproducing-runs.html
I reproduced the crash using:
simics> @tsffs.iface.fuzz.repro("%simics%/corpus/4385dc33f608888d")
The simulation runs once with the specified input. After execution, Simics allows debugging using:
simics> reverse-to start
However, as documented:
Fuzzing cannot be resumed after entering repro mode due to inconsistencies with the simulated system clock.
My questions:
Is there any supported way to:
> Reproduce a crash from a solution seed
> Debug it
> And then continue fuzzing from the previous session state?
If resuming is not possible by design, what is the recommended workflow for:
> Efficient crash reproduction
> Deep debugging
> And continuing fuzzing afterward?
We are fuzzing an EDK2 application built under simicsOpenBoardPkg using TSFFS with Simics.
The fuzzing configuration includes:
Exceptions 3, 6, and 14 are treated as solutions. When any of these exceptions occur, the corresponding input seed is saved in the solution directory.
During an active fuzzing session:
A crash was detected.
The crashing input seed was saved in the solution directory.
The fuzzing session was interrupted using Ctrl + C.
Following the official reproduction guide:
https://intel.github.io/tsffs/tutorials/edk2-uefi/reproducing-runs.html
I reproduced the crash using:
simics> @tsffs.iface.fuzz.repro("%simics%/corpus/4385dc33f608888d")The simulation runs once with the specified input. After execution, Simics allows debugging using:
simics> reverse-to startHowever, as documented:
Fuzzing cannot be resumed after entering repro mode due to inconsistencies with the simulated system clock.
My questions:
Is there any supported way to:
> Reproduce a crash from a solution seed
> Debug it
> And then continue fuzzing from the previous session state?
If resuming is not possible by design, what is the recommended workflow for:
> Efficient crash reproduction
> Deep debugging
> And continuing fuzzing afterward?