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