[FFmpeg-devel] [PATCH] Gsoc: add the two fuzzy targets

[Michael Niedermayer]

On Thu, Apr 22, 2021 at 04:13:56PM +0800, Heng Zhang wrote:
> 
> 
> > 在 2021年4月20日，下午7:12，Michael Niedermayer <michael at niedermayer.cc> 写道：
> > 
> > On Tue, Apr 20, 2021 at 12:34:13PM +0800, Heng Zhang wrote:
> >> 
> >> 
> >>> 在 2021年4月19日，下午5:47，Michael Niedermayer <michael at niedermayer.cc> 写道：
> >>> 
> >>> On Mon, Apr 19, 2021 at 05:06:10PM +0800, a397341575 at 163.com <mailto:a397341575 at 163.com> wrote:
> >>>> From: toseven <Byone.heng at gmail.com>
> > [...]
> >>>> +    if (ret < 0)
> >>>> +    {
> >>>> +        fprintf(stderr, "Error occurred in av_packet_add_side_data: %s\n",
> >>>> +        av_err2str(ret));
> >>>> +    }
> >>>> +    return ret;
> >>> 
> >>> the { } placing style mismatches whats used in FFmpeg (i dont mind but some people do mind)
> >>> 
> >>> more general, how much code coverage is gained with these 2 fuzzers compared to what already exists ?
> >>> 
> >>> thanks
> >> 
> >> Okay, I will modify my style to adopt for FFmpeg. What is more, I didn’t compare the code coverage between them. Do I have to do this?  I mainly refer to the fate test from libavcodec/tests/avpacket.c and libavfilter/tests/formats.c.
> > 
> > If code coverage does not improve, what would be the reason for FFmpeg to
> > include the code ?
> 
> Thank your reply. 
> My fuzzing targets call the new API interfaces, which are not used by the existing fuzzing target. Though I don’t do the related experiment, code coverage should improve. 

Current fuzzer coverage can be seen here:
https://storage.googleapis.com/oss-fuzz-coverage/ffmpeg/reports/20210420/linux/src/ffmpeg/report.html

You are adding 2 targets
target_avpacket_fuzzer:
this calls
av_packet_side_data_name, av_packet_add_side_data, av_packet_free, av_packet_clone, av_grow_packet, av_new_packet, av_packet_from_data, 
From these all but av_packet_clone and av_packet_side_data_name are covered already
av_packet_side_data_name() is called with a fixed argument in your code

target_formats_fuzzer:
this calls av_get_channel_layout_string, ff_parse_channel_layout
the first is already covered the second is in libavfilter
libavfilter needs to be fuzzed, such fuzzing would involve building
filter chains or networks based on fuzzer input.
A 2nd set of libavfilter fuzzers should similar to libavcodec fuzzers
generate 1 fuzzer generically for each avfilter similarly to how decoders
from libavcodec are fuzzed.
Such libavfilter fuzzers would then also test most functions within libavfilter

More generally about coverage.
If you where in my position what would you want for additional fuzzers ?
maximally increased coverage with mininmal effort ?
I belive this would be achieved with generic fuzzing of filters similar to how
decoders are fuzzed currently. But thats a bit bigger effort 

I see the gsoc page says connecting 2 fate tests to fuzzing can be used as
qualification task. 
For connecting such tests, the fate test and the fuzzer should use shared
code and not duplicate. One way that can work is that the fate test takes
some input and that input is fixed for fate but can change when used for fuzzing
again, the more coverage we can achieve with as little effort the better.
Basically dont be afraid to submit a small amount of code because in fact
i would be more impressed if you can connect fate test(s) with little code
to the fuzzer than with alot of code.

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210422/8b65c433/attachment.sig>