Re: [PATCH 2/2] Add scripts/oss-fuzz/build.sh

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Tue, Jun 25, 2024 at 7:40 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 25.06.2024 13:15, Tamas K Lengyel wrote:
> > On Tue, Jun 25, 2024 at 5:17 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 21.06.2024 21:14, Tamas K Lengyel wrote:
> >>> --- /dev/null
> >>> +++ b/scripts/oss-fuzz/build.sh
> >>> @@ -0,0 +1,22 @@
> >>> +#!/bin/bash -eu
> >>> +# Copyright 2024 Google LLC
> >>> +#
> >>> +# Licensed under the Apache License, Version 2.0 (the "License");
> >>> +# you may not use this file except in compliance with the License.
> >>> +# You may obtain a copy of the License at
> >>> +#
> >>> +#      http://www.apache.org/licenses/LICENSE-2.0
> >>> +#
> >>> +# Unless required by applicable law or agreed to in writing, software
> >>> +# distributed under the License is distributed on an "AS IS" BASIS,
> >>> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
> >>> implied.
> >>> +# See the License for the specific language governing permissions and
> >>> +# limitations under the License.
> >>> +#
> >>> +################################################################################
> >>
> >> I'm a little concerned here, but maybe I shouldn't be. According to what
> >> I'm reading, the Apache 2.0 license is at least not entirely compatible
> >> with GPLv2. While apparently the issue is solely with linking in Apache-
> >> licensed code, I wonder whether us not having a respective file under
> >> ./LICENSES/ (and no pre-cooked SPDX identifier to use) actually has a
> >> reason possibly excluding the use of such code in the project.
> >>
> >>> +cd xen
> >>> +./configure clang=y --disable-stubdom --disable-pvshim --disable-docs 
> >>> --disable-xen
> >>> +make clang=y -C tools/include
> >>> +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness
> >>> +cp tools/fuzz/x86_instruction_emulator/libfuzzer-harness 
> >>> $OUT/x86_instruction_emulator
> >>
> >> In addition to what Julien said, I further think that filename / directory
> >> name are too generic for a file with this pretty specific contents.
> >
> > I don't really get your concern here?
>
> The thing that is built is specifically a x86 emulator piece of fuzzing
> binary. Neither the directory name nor the file name contain either x86
> or (at least) emul.

Because this build script is not necessarily restricted to build only
this one harness in the future. Right now that's the only one that has
a suitable libfuzzer harness, but the reason this build script is here
is to be easily able to add additional fuzzing binaries without the
need to open PRs on the oss-fuzz repo, which as I understand no one
was willing to do in the xen community due to the CLA. Now that the
integration is going to be in oss-fuzz, the only thing you have to do
in the future is add more stuff to this script to get fuzzed. Anything
that's compiled with libfuzzer and copied to $OUT will be picked up by
oss-fuzz automatically. Makes sense?

Tamas