| Message ID | d0974cc40ca68fe197ba7941edd934970d3a92cf.1719355322.git.tamas@tklengyel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/2] Add libfuzzer target to fuzz/x86_instruction_emulator | expand |
On 26.06.2024 00:47, Tamas K Lengyel wrote: > --- /dev/null > +++ b/scripts/oss-fuzz/build.sh > @@ -0,0 +1,23 @@ > +#!/bin/bash -eu > +# SPDX-License-Identifier: Apache-2.0 Hmm. Aiui this line is supposed to make unnecessary ... > +# 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. ... all of this text, provided an entry is first put in ./LICENSES/. > +################################################################################ > + > +cd xen This looks to suggest that the expectation is for the script to be invoked from the root of a xen.git clone. Imo something like cd $(dirname $0)/../../xen would be more flexible. > +./configure --disable-stubdom --disable-pvshim --disable-docs --disable-xen Going forward we mean to no longer bundle e.g. qemu in release tarballs, yet I wonder whether passing a couple of --with-system-...= here wouldn't be better nevertheless. > +make clang=y -C tools/include > +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness In how far is it a requirement to have "clang=y" here? Wasn't this question even asked before? I'm not even sure whether mid- or long-term we mean to retain that functionality. Overrides of tool chain (components) may better be done using CC= and friends. Plus perhaps by whoever is invoking this script? Jan
On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 26.06.2024 00:47, Tamas K Lengyel wrote: > > --- /dev/null > > +++ b/scripts/oss-fuzz/build.sh > > @@ -0,0 +1,23 @@ > > +#!/bin/bash -eu > > +# SPDX-License-Identifier: Apache-2.0 > > Hmm. Aiui this line is supposed to make unnecessary ... > > > +# 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. > > ... all of this text, provided an entry is first put in ./LICENSES/. > > > +################################################################################ > > + > > +cd xen > > This looks to suggest that the expectation is for the script to be invoked > from the root of a xen.git clone. Imo something like > > cd $(dirname $0)/../../xen > > would be more flexible. No, it will be invoked after a git clone is made, so you have to enter the xen folder that was just cloned. > > > +./configure --disable-stubdom --disable-pvshim --disable-docs --disable-xen > > Going forward we mean to no longer bundle e.g. qemu in release tarballs, > yet I wonder whether passing a couple of --with-system-...= here wouldn't > be better nevertheless. It largely doesn't matter as long as the configure script completes successfully since we aren't going to compile QEMU. But sure, I can add it. > > > +make clang=y -C tools/include > > +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness > > In how far is it a requirement to have "clang=y" here? Wasn't this question > even asked before? I'm not even sure whether mid- or long-term we mean to > retain that functionality. Overrides of tool chain (components) may better > be done using CC= and friends. Plus perhaps by whoever is invoking this > script? It is an absolute requirement to use clang=y here as oss-fuzz uses a specific clang as compiler for C/C++ projects. The CC environment variables are already set by the oss-fuzz docker environment but it's insufficient for a successful clang build. Without clang=y the following error is encountered: gcc: error: unrecognized debug output level 'line-tables-only' gcc: error: unrecognized argument to '-fsanitize=' option: 'fuzzer-no-link' Tamas
On 18.07.2024 14:54, Tamas K Lengyel wrote: > On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich <jbeulich@suse.com> wrote: >> On 26.06.2024 00:47, Tamas K Lengyel wrote: >>> +cd xen >> >> This looks to suggest that the expectation is for the script to be invoked >> from the root of a xen.git clone. Imo something like >> >> cd $(dirname $0)/../../xen >> >> would be more flexible. > > No, it will be invoked after a git clone is made, so you have to enter > the xen folder that was just cloned. Yet the suggested alternative would still work then, wouldn't it? And it would permit easier use of the script from outside of that very specific environment, e.g. when wanting to re-invoke it without running a full cloning process every time. >>> +make clang=y -C tools/include >>> +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness >> >> In how far is it a requirement to have "clang=y" here? Wasn't this question >> even asked before? I'm not even sure whether mid- or long-term we mean to >> retain that functionality. Overrides of tool chain (components) may better >> be done using CC= and friends. Plus perhaps by whoever is invoking this >> script? > > It is an absolute requirement to use clang=y here as oss-fuzz uses a > specific clang as compiler for C/C++ projects. The CC environment > variables are already set by the oss-fuzz docker environment but it's > insufficient for a successful clang build. Without clang=y the > following error is encountered: > > gcc: error: unrecognized debug output level 'line-tables-only' > gcc: error: unrecognized argument to '-fsanitize=' option: 'fuzzer-no-link' Could you add a sentence to this effect to the description? Jan
On Thu, Jul 18, 2024 at 9:03 AM Jan Beulich <jbeulich@suse.com> wrote: > > On 18.07.2024 14:54, Tamas K Lengyel wrote: > > On Thu, Jul 18, 2024 at 7:17 AM Jan Beulich <jbeulich@suse.com> wrote: > >> On 26.06.2024 00:47, Tamas K Lengyel wrote: > >>> +cd xen > >> > >> This looks to suggest that the expectation is for the script to be invoked > >> from the root of a xen.git clone. Imo something like > >> > >> cd $(dirname $0)/../../xen > >> > >> would be more flexible. > > > > No, it will be invoked after a git clone is made, so you have to enter > > the xen folder that was just cloned. > > Yet the suggested alternative would still work then, wouldn't it? And > it would permit easier use of the script from outside of that very > specific environment, e.g. when wanting to re-invoke it without > running a full cloning process every time. This script is specifically made for that one environment and is not intended to be invoked from anywhere else. I don't think we need to complicate this needlessly. > > >>> +make clang=y -C tools/include > >>> +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness > >> > >> In how far is it a requirement to have "clang=y" here? Wasn't this question > >> even asked before? I'm not even sure whether mid- or long-term we mean to > >> retain that functionality. Overrides of tool chain (components) may better > >> be done using CC= and friends. Plus perhaps by whoever is invoking this > >> script? > > > > It is an absolute requirement to use clang=y here as oss-fuzz uses a > > specific clang as compiler for C/C++ projects. The CC environment > > variables are already set by the oss-fuzz docker environment but it's > > insufficient for a successful clang build. Without clang=y the > > following error is encountered: > > > > gcc: error: unrecognized debug output level 'line-tables-only' > > gcc: error: unrecognized argument to '-fsanitize=' option: 'fuzzer-no-link' > > Could you add a sentence to this effect to the description? Sure. Thanks, Tamas
On Tue Jun 25, 2024 at 11:47 PM BST, Tamas K Lengyel wrote: > The build integration script for oss-fuzz targets. Future fuzzing targets can > be added to this script and those targets will be automatically picked up by > oss-fuzz without having to open separate PRs on the oss-fuzz repo. > > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> > --- > scripts/oss-fuzz/build.sh | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > create mode 100755 scripts/oss-fuzz/build.sh > > diff --git a/scripts/oss-fuzz/build.sh b/scripts/oss-fuzz/build.sh > new file mode 100755 > index 0000000000..2cfd72adf1 > --- /dev/null > +++ b/scripts/oss-fuzz/build.sh > @@ -0,0 +1,23 @@ > +#!/bin/bash -eu The shebang probably wants to be "/usr/bin/env bash" to account for systems that don't have bash specifically there. With that "-eu" would need to move down a line to be "set -eu" > +# SPDX-License-Identifier: Apache-2.0 > +# 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. > +# > +################################################################################ > + > +cd xen > +./configure --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 Cheers, Alejandro
On Thu, Jul 18, 2024 at 1:36 PM Alejandro Vallejo <alejandro.vallejo@cloud.com> wrote: > > On Tue Jun 25, 2024 at 11:47 PM BST, Tamas K Lengyel wrote: > > The build integration script for oss-fuzz targets. Future fuzzing targets can > > be added to this script and those targets will be automatically picked up by > > oss-fuzz without having to open separate PRs on the oss-fuzz repo. > > > > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> > > --- > > scripts/oss-fuzz/build.sh | 23 +++++++++++++++++++++++ > > 1 file changed, 23 insertions(+) > > create mode 100755 scripts/oss-fuzz/build.sh > > > > diff --git a/scripts/oss-fuzz/build.sh b/scripts/oss-fuzz/build.sh > > new file mode 100755 > > index 0000000000..2cfd72adf1 > > --- /dev/null > > +++ b/scripts/oss-fuzz/build.sh > > @@ -0,0 +1,23 @@ > > +#!/bin/bash -eu > > The shebang probably wants to be "/usr/bin/env bash" to account for systems > that don't have bash specifically there. > > With that "-eu" would need to move down a line to be "set -eu" Thanks but this script is specifically made for just one environment and does not need to account for other systems. Cheers, Tamas
diff --git a/scripts/oss-fuzz/build.sh b/scripts/oss-fuzz/build.sh new file mode 100755 index 0000000000..2cfd72adf1 --- /dev/null +++ b/scripts/oss-fuzz/build.sh @@ -0,0 +1,23 @@ +#!/bin/bash -eu +# SPDX-License-Identifier: Apache-2.0 +# 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. +# +################################################################################ + +cd xen +./configure --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
The build integration script for oss-fuzz targets. Future fuzzing targets can be added to this script and those targets will be automatically picked up by oss-fuzz without having to open separate PRs on the oss-fuzz repo. Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com> --- scripts/oss-fuzz/build.sh | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100755 scripts/oss-fuzz/build.sh