On Mon, Jul 22, 2024 at 9:57 AM Jan Beulich <jbeul...@suse.com> wrote: > > On 22.07.2024 15:51, Tamas K Lengyel wrote: > > On Mon, Jul 22, 2024 at 8:24 AM Jan Beulich <jbeul...@suse.com> wrote: > >> > >> On 22.07.2024 13:27, Tamas K Lengyel wrote: > >>> This target enables integration into oss-fuzz. Changing invalid input > >>> return > >>> to -1 as values other then 0/-1 are reserved by libfuzzer. Also adding the > >>> missing __wrap_vsnprintf wrapper which is required for successful oss-fuzz > >>> build. > >>> > >>> Signed-off-by: Tamas K Lengyel <ta...@tklengyel.com> > >>> --- > >>> v3: don't include libfuzzer-harness in target 'all' as it requires > >>> specific cc > >> > >> With this, how is it going to be built at all? Only by invoking the special > >> target "manually" as it seems? Which sets this up for easy bit-rotting. I > >> wonder what others think here ... > > > > Yes, by calling make with the specific target. It's not going to > > bitrot because oss-fuzz will pick up any regression on a daily basis > > to this target. I assume you would be interested in receiving the > > fuzzing reports so it would show as a build failure in case something > > broke it. > > Please forgive my lack of knowledge here, but which part of whose > infrastructure would pick up stuff in a daily basis, and what fuzzing > reports (I've never seen any, daily or not) are you talking about? > For now it feels to me as if you're talking of what's possible down > the road, not what's going to happen from the moment this patch was > committed in a 2nd try. If so, the gap between both points in time > may be significant, and hence my bit-rotting concern would still > apply.
Once these two patches are merged to Xen I'll send my PR to oss-fuzz to have it pull Xen daily and build this fuzzer and run it on their infrastructure. It usually takes them less than 24 hours to respond to PRs, I have added multiple projects there already so the "lag" you worry about it's not something to worry about. Having these two patches upstream in Xen is not required by the way, I could just send these to be upstream to oss-fuzz and have them apply them after it pulling the xen git repo but it gives more flexibility to you guys to add additional fuzzers in the future more easily if these are in your repository because you don't even have to touch oss-fuzz afterwards. If you need to learn more about what oss-fuzz is and how it operates they have a quite nice documentation. Tamas
