On Mon, Sep 02, 2024 at 03:46:26PM +0100, Daniel P. Berrangé wrote:
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 ?
Oh, I thought the link to the write-up was somewhere in here, sorry. https://gitlab.com/Skryptonyte/libvirt-gsoc-finalreport
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 ?
See the link above. Once The fuzzing is running (and it had pretty quick results for me) it is written in a way that the conflicting XMLs can be produced from the results.
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 :-(
It is definitely possible, the question is how long until that becomes stale/out of date.
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 :|
signature.asc
Description: PGP signature
