3.7 KiB
| layout | title | parent | nav_order | permalink |
|---|---|---|---|---|
| default | Fuzzer environment | Further reading | 2 | /further-reading/fuzzer-environment/ |
Fuzzer environment on ClusterFuzz
Your fuzz targets will be run on a Google Compute Engine VM (Linux) with some security restrictions.
- TOC {:toc}
Runtime Dependencies
You should not make any assumptions on the availability of dependent packages in the execution environment. Packages that are installed via [Dockerfile]({{ site.baseurl }}/getting-started/new-project-guide/#dockerfile) or built as part of [build.sh]({{ site.baseurl }}/getting-started/new-project-guide/#buildsh) are not available on the bot runtime environment (where the fuzz targets run).
If you need these dependencies in the runtime environment, you can either:
- Install the packages via Dockerfile (example) and then link statically against them (example).
- Or build the dependencies statically in [build.sh]({{ site.baseurl }}/getting-started/new-project-guide/#buildsh) (example).
All build artifacts needed during fuzz target execution should be inside the
$OUT directory. Only those artifacts are archived and used on the bots.
Everything else is ignored (e.g. artifacts in $WORK, $SRC, etc) and hence
is not available in the execution environment.
We strongly recommend static linking because it just works.
However dynamic linking can work if shared objects are included in the $OUT directory and are loaded relative
to '$ORIGIN', the path of the binary (see the discussion of '$ORIGIN' here).
A fuzzer can be instructed to load libraries relative to '$ORIGIN' during compilation (i.e. -Wl,-rpath,'$ORIGIN/lib' )
or afterwards using chrpath -r '$ORIGIN/lib' $OUT/$fuzzerName (example). Note that '$ORIGIN' should be surrounded
by single quotes because it is not an environment variable like $OUT that can be retrieved during execution of build.sh.
Its value is retrieved during execution of the binary. You can verify that you did this correctly using ldd <fuzz_target_name> and the check_build command in infra/helper.py.
You should ensure that the fuzz target works correctly by using run_fuzzer
command (see instructions
[here]({{ site.baseurl }}/getting-started/new-project-guide/#testing-locally)).
This command uses a clean base-runner docker container and not the base-builder
docker container created during build-time.
argv[0]
You must not modify argv[0]. It is required for certain things to work
correctly.
Current working directory
You should not make any assumptions about the current working directory of your
fuzz target. If you need to load data files, please use argv[0] to get the
directory where your fuzz target executable is located.
File system
Everything except /tmp is read-only, including the directory that your fuzz
target executable lives in.
/dev is also unavailable.
Hardware
Your project should not be compiled with -march=native or -mtune=native
flags, as the build infrastructure and fuzzing machines may have different CPUs
as well as other hardware differences. You may however use -mtune=generic.