1--- 2layout: default 3title: Fuzzer environment 4parent: Further reading 5nav_order: 2 6permalink: /further-reading/fuzzer-environment/ 7--- 8 9# Fuzzer environment on ClusterFuzz 10 11Your fuzz targets will be run on a 12[Google Compute Engine](https://cloud.google.com/compute/) VM (Linux). 13 14- TOC 15{:toc} 16--- 17 18## Runtime Dependencies 19 20You should not make any assumptions on the availability of dependent packages 21in the execution environment. Packages that are installed via 22[Dockerfile]({{ site.baseurl }}/getting-started/new-project-guide/#dockerfile) 23or built as part of 24[build.sh]({{ site.baseurl }}/getting-started/new-project-guide/#buildsh) 25are not available on the bot runtime environment (where the fuzz targets run). 26 27If you need these dependencies in the runtime environment, you can either: 28- Install the packages via Dockerfile 29([example](https://github.com/google/oss-fuzz/blob/2d5e2ef84f281e6ab789055aa735606d3122fda9/projects/tor/Dockerfile#L19)) 30and then link statically against them 31([example](https://github.com/google/oss-fuzz/blob/2d5e2ef84f281e6ab789055aa735606d3122fda9/projects/tor/build.sh#L40)). 32- Or build the dependencies statically in 33[build.sh]({{ site.baseurl }}/getting-started/new-project-guide/#buildsh) 34([example](https://github.com/google/oss-fuzz/blob/64f8b6593da141b97c98c7bc6f07df92c42ee010/projects/ffmpeg/build.sh#L26)). 35 36All build artifacts needed during fuzz target execution should be inside the 37`$OUT` directory. Only those artifacts are archived and used on the bots. 38Everything else is ignored (e.g. artifacts in `$WORK`, `$SRC`, etc) and hence 39is not available in the execution environment. 40 41We strongly recommend static linking because it just works. 42However dynamic linking can work if shared objects are included in the `$OUT` directory and are loaded relative 43to `'$ORIGIN'`, the path of the binary (see the discussion of `'$ORIGIN'` [here](http://man7.org/linux/man-pages/man8/ld.so.8.html)). 44A fuzzer can be instructed to load libraries relative to `'$ORIGIN'` during compilation (i.e. `-Wl,-rpath,'$ORIGIN/lib'` ) 45or afterwards using `chrpath -r '$ORIGIN/lib' $OUT/$fuzzerName` ([example](https://github.com/google/oss-fuzz/blob/09aa9ac556f97bd4e31928747eca0c8fed42509f/projects/php/build.sh#L40)). Note that `'$ORIGIN'` should be surrounded 46by single quotes because it is not an environment variable like `$OUT` that can be retrieved during execution of `build.sh`. 47Its 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`. 48 49You should ensure that the fuzz target works correctly by using `run_fuzzer` 50command (see instructions 51[here]({{ site.baseurl }}/getting-started/new-project-guide/#testing-locally)). 52This command uses a clean base-runner docker container and not the base-builder 53docker container created during build-time. 54 55## argv[0] 56 57You must not modify `argv[0]`. It is required for certain things to work 58correctly. 59 60## Current working directory 61 62You should not make any assumptions about the current working directory of your 63fuzz target. If you need to load data files, please use `argv[0]` to get the 64directory where your fuzz target executable is located. 65 66## File system 67 68Everything except `/tmp` is read-only, including the directory that your fuzz 69target executable lives in. 70 71`/dev` is also unavailable. 72 73## Hardware 74 75Your project should not be compiled with `-march=native` or `-mtune=native` 76flags, as the build infrastructure and fuzzing machines may have different CPUs 77as well as other hardware differences. You may however use `-mtune=generic`. 78