Re: [PATCH 00/14] Introduce fuzzing of XML formats

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 :|