On Tue, Aug 27, 2024 at 10:06:58AM +0200, Martin Kletzander wrote:
On Tue, Aug 20, 2024 at 03:03:47PM +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 19, 2024 at 09:39:38PM +0530, Rayhan Faizel wrote:
> > This series introduces multiple fuzzers developed as part of Google Summer
> > of Code 2024. We adopt a structure-aware fuzzing approach to fuzz libvirt
> > XML formats. The fuzzing methodology makes use of libFuzzer and
> > libprotobuf-mutator. The fuzzers work by mutating intermediate protobufs
> > and converting them to XML.
> >
> > The fuzzing method in use requires inclusion of C++ sources. However, C++
> > compilation will be done only if '-Dfuzz' is enabled. Otherwise,
libvirt will
> > compile normally as before. The fuzzing method works only on clang compilers
> > which support libFuzzer.
>
> Hmm, I wish you'd raised this issue on the list before investing all
> this work becasue IMHO the dependency on C++ is not something I would
> want to see in the libvirt project, even just for tests. It was a
> very delibrate decision that libvirt be a C project, not C++ project,
> and if we're going to extend libvirt to take code in any new language
> the choices that make sense looking to the future are Rust or Go,
> not C++.
>
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.
Do you have pointers to the list of things that it found ?
The crucial part of this is the existing libprotobuf-mutator which
is
already in C++ and does provide very specific C++ APIs.
I'm struggling a little to understand exactly what kind of changes
this code actually produces ? Are there examples of the mutated
XML files showing these changes ?
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++.
If we could have it in a separate repo, and NOT have to change libvirt
code to avoid C++ keywords/etc, then that could make it more palatable.
Ultimately though the libvirt maintainers are still on the hook to
maintain C++ code long term now, so a separate repo just stops the
C++ stuff spreading :-(
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|