Closed B03901108 closed 3 months ago
For Question 2, I ran Hoedur with the options --fuzzware --fuzzware-binary=$HOME/.virtualenvs/fuzzware/bin/fuzzware
. It worked but with a few errors from angr and lower coverage than a vanilla Hoedur (in uEmu/3Dprinter). Is the above the right way to run Fuzzware on top of Hoedur?
The frequent model generations at the beginning of a fuzzing run seemed to interrupt Hoedur's input mutations much. Still, I wonder if the use of Fuzzware becomes worthwhile in the long term (e.g., after 24 hours of fuzzing).
Did Fuzzware significantly improve Hoedur's code coverage or ability to catch bugs in your past experiments?
We built and optimized Hoedur without models to ensure the multi-streams are working as expected. For improved efficiency and to have a better comparison with Fuzzware we use the Fuzzware modeling. We did an ablation study where Hoedur outperformed Fuzzware on most targets without models. With models Hoedur does perform significantly (depending on your concrete interpretation) better.
Could you share some guidance on applying locally built Fuzzware to Hoedur?
We have prepared a Hoedur docker container that includes Fuzzware: https://github.com/fuzzware-fuzzer/hoedur-experiments/blob/main/scripts/hoedur/hoedur-fuzzware.dockerfile We also have a short guide on installing Fuzzware locally: https://github.com/fuzzware-fuzzer/fuzzware?tab=readme-ov-file#fuzzware-on-host
Is the above the right way to run Fuzzware on top of Hoedur?
No, the recommended way is to use the Fuzzware docker.
Could you recommend some files/modules/interfaces in Hoedur to start with?
The Fuzzware integration is part of the modeling
crate, see https://github.com/fuzzware-fuzzer/hoedur/tree/main/modeling/src/fuzzware
The frequent model generations at the beginning of a fuzzing run seemed to interrupt Hoedur's input mutations much.
Consider using a model share (--model-share
) to re-use models between multiple instances and runs.
Still, I wonder if the use of Fuzzware becomes worthwhile in the long term (e.g., after 24 hours of fuzzing).
It does after some minutes, depending on the target and correct use of the fuzzer.
We provided scripts to handle running Hoedur in the intended way, please families your self with them: https://github.com/fuzzware-fuzzer/hoedur-experiments?tab=readme-ov-file#running-hoedur-on-a-given-target
@SWW13 What is the difference between using Fuzzware in the docker container and using Fuzzware installed locally?
To be specific, what's wrong with --fuzzware-binary=$HOME/.virtualenvs/fuzzware/bin/fuzzware
where the installed Fuzzware was the latest main version (commit 81fb4fc)?
Also, I tried fuzz-local.py and could not find the option for assigning multiple cores to a fuzzing instance.
--cores
specifies the total cores available to schedule all the instances,
in which case each instance still runs on a single core.
Is there an option for assigning multiple cores to a specific instance? Thank you.
What is the difference between using Fuzzware in the docker container and using Fuzzware installed locally? To be specific, what's wrong with --fuzzware-binary=$HOME/.virtualenvs/fuzzware/bin/fuzzware
The docker installation is tested and supported by use. The fuzzware-binary
is intended to be used inside the hoedur docker which is based on the fuzzware docker.
If you are use a custom local installation you have to figure out if every thing is working as expected and troubleshot issues yourself.
Is there an option for assigning multiple cores to a specific instance?
No, Hoedur is designed to run on a single core per fuzzer instance. Only the models are shared between instances when a model share is used.
@SWW13 Got it.
The difference between using Fuzzware in Docker vs. locally installed seems to be reduced to the referred Fuzzware binary.
FuzzwareRunner abstracts these two options away from Hoedur's call to fuzzware-modeling
.
As I would like to try some tweaked Fuzzware upon Hoedur, I may stick with the locally installed one.
Hoedur only runs each fuzzer instance on a single core. So, when Hoedur's paper says "run each fuzzer five times ..., with each run being assigned four physical CPU cores", does it mean four (concurrent?) instances with no coordination except MMIO-model sharing?
I would like to try some tweaked Fuzzware upon Hoedur, I may stick with the locally installed one.
I see.
does it mean four (concurrent?) instances with no coordination except MMIO-model sharing?
Correct, we ran 20 (5x4) independent (except modeling) instances and grouped the result (coverage) in groups of 4 (run 1-4, 5-8, ...). We did simplify this in the paper to avoid confusion with technical details that have no impact on the result.
Thank you so much for all the clarifications. I have no further questions regarding this issue.
Dear Hoedur authors, I have three questions about Hoedur's support for MMIO modeling. Thank you so much.
I saw both on the paper and in the project that Hoedur can work with Fuzzware. Did Fuzzware significantly improve Hoedur's code coverage or ability to catch bugs in your past experiments?
I ran Hoedur with the option
--fuzzware
. It required a connection to Docker for retrieving Fuzzware's image. Could you share some guidance on applying locally built Fuzzware to Hoedur?I plan to use my MMIO models on top of Hoedur. Could you recommend some files/modules/interfaces in Hoedur to start with?