Unable to Resume Fuzzing Session After Reproducing Crash via tsffs.iface.fuzz.repro
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Ambito
- embedded-iot, testing-qa
Direzione di ricerca
Inizia con la guida ufficiale reproducing-runs e con il workflow segnalato tsffs.iface.fuzz.repro e reverse-to start. Determina se la sessione di fuzzing precedente può essere ripresa dopo la modalità repro e documenta il workflow supportato per la riproduzione dei crash, il debugging e la continuazione del fuzzing, oppure indica chiaramente che la ripresa non è supportata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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?
- Lingua principale
- Rust
- Stelle
- 335
- Fork
- 26
- Merge medio
- 1g 50m
- PR unite (30g)
- 12
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di intel/tsffs
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
bug UI
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
wardian-app/Wardian#1746 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
jlcodes99/cockpit-tools#3125 ·
I maintainer di solito rispondono entro 2 giorni
-
bug user-sprint
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Vondor/KassenSturz#967 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
area:build bug effort:low P5 source:agent
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno