An Azure Blob Storage Container. Each fuzzing task has a set of required and potentially optional containers that are used in a specific context.
As an example, the libFuzzer fuzzing task uses the following:
setup: A container with the libFuzzer target executable and any prerequisites
(shared objects, DLLs, config files, etc)crashes: A container used to store any crashing inputinputs: A container of an initial corpus of seeding input for the libFuzzer
target. Any newly discovered inputs are also saved to this container. All
files saved in the inputs container are bidirectionally synced with the blob
store.readonly_inputs: An arbitrary set of additional input seed corpus containers.
This container automatically pulls new files from the blob store, but
nothing saved to these containers on the fuzzing VM is synced to the
container.Tasks can target a container for an input queue. As an example, the crash
reporting tasks queue off of specified crashes containers, processing files
iteratively from the queue.
Users can create arbitrary containers (see Container Name Requirements), including the ability to set arbitrary metadata for a container.
Templates use containers built from the context it’s being used (setup) and a
namespaced GUID to enable automatic re-use of containers across multiple builds
of the same target. NOTE: A helper utility is available to craft namespaced
GUIDs onefuzz utils namespaced_guid.
As an example, setup and coverage containers are namespaced with the project,
name, build, and platform (Linux or Windows). All other containers
(inputs, crashes, reports, etc) use project and name.
Example:
The libfuzzer template with the project ‘myproject’, the name of ‘mytarget’,
and build of build_1 on the Linux platform uses the following:
The same target, but build_2 uses the following containers:
The only difference is a unique oft-setup container.
In these examples, oft stands for OneFuzz Template “setup” container.