Your fuzz targets will be run on a Google Compute Engine VM (Linux) with some security restrictions.
You should not make any assumptions on the availability of dependent packages in the execution environment. Packages that are installed via Dockerfile or built as part of build.sh 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 (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.
You should ensure that the fuzz target works correctly by using run_fuzzer command
(see instructions here). This command uses
a clean base-runner docker container and not the base-builder docker container
created during build-time.
You must not modify argv[0]. It is required for certain things to work correctly.
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.
Everything except /tmp is read-only, including the directory that your fuzz target
executable lives in.
/dev is also unavailable.
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.
There will be no network interfaces available (not even loopback).