[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Mon, Jun 13, 2011 at 02:43:00PM +0100, Julio Merino wrote:
> Not sure. Before adding this to ATF, I'd like to see the code working
> in NetBSD along with some use cases for it. When it's proven to be
> useful, we can abstract the implementation and move it into ATF. (My
> main concern is that I have no idea how this would look like for the use
> cases you mention, and would also like to see "wide" acceptance by the
> main consumer of ATF before doing this ;-)
ATF would be the natural place to put this. I could write it myself quickly
enough, but I am not too eager to write C++...
> Maybe a little design doc with some use cases and examples of the API
> and its users would be good to clarify what you have in mind.
I don't think something like this requires a profound design document.
A lot has been however written about fuzzing in the literature. Basically
you just feed random garbage as input to applications, system calls, library
routines, etc. A great deal of security bugs is (still today) found by this
> The question here would be: why rewrite the fuzzer if others exist?
Because writing one would be easy. Also: none of the existing fuzzers I have
looked at meet the general code quality requirements.
Main Index |
Thread Index |