On Tue, Aug 27, 2024 at 12:08:27PM +0300, Rayhan Faizel wrote:
On Tue, Aug 27, 2024 at 11:07 AM Martin Kletzander <mkletzan@xxxxxxxxxx> wrote:That was unfortunate, but since Rayhan had the first implementation done in a very short time we rather spent the rest of the time enhancing the fuzzing and it definitely bore fruit -- some of the found things are fixed, some are still waiting for a patch or two. The crucial part of this is the existing libprotobuf-mutator which is already in C++ and does provide very specific C++ APIs. Another approach (except writing our own mutator) would be to keep the code in a separate repository. I'm not completely sure whether we would still need the code modifications, I don't remember our discussions about whether the fuzzing compilation could work with all current libvirt code compiled as C and only the fuzzing parts compiled in C++.All the existing code is indeed still compiled as C. Only the fuzzing executables (under tests/fuzz/) are compiled in C++ and linked to those C objects. We still do need some of the minor code modifications (in PATCH 1) because existing C headers are sometimes interpreted a bit differently from the fuzzer's PoV, even with C linkage.
Sorry, what I meant is whether it would be possible to keep the code as is, the keyword parameters are a bit of a problem, but writing a layer of C code to call it through from the C++ code feels weird. Of course attributes are also complicated to make work, but those changes in the C code are pretty okay I think.
There are still some other code modifications in tests/ and src/ for a few other fuzzers (mostly hotplug and CH) to make fuzzing easier. I agree that we could keep it as a separate repo, perhaps a subproject. I have seen some projects keep their fuzzing code separate (mostly on oss-fuzz). -- Rayhan Faizel
Attachment:
signature.asc
Description: PGP signature