onefuzz/docs/containers.md

69 lines
3.0 KiB
Markdown

# Containers in OneFuzz
An
[Azure Blob Storage Container](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction).
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 input
* `inputs`: 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.
## Considerations on naming Containers
Users can create arbitrary containers (see
[Container Name Requirements](https://docs.microsoft.com/en-us/rest/api/storageservices/Naming-and-Referencing-Containers--Blobs--and-Metadata#container-names)),
including the ability to set
[arbitrary metadata](https://docs.microsoft.com/en-us/rest/api/storageservices/setting-and-retrieving-properties-and-metadata-for-blob-resources)
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:
* oft-setup-fd4addc373f3551caf780e80abaaa658
* oft-coverage-fd4addc373f3551caf780e80abaaa658
* oft-inputs-d532156b72765c21be5a29f73718af7e
* oft-crashes-d532156b72765c21be5a29f73718af7e
* oft-reports-d532156b72765c21be5a29f73718af7e
* oft-unique-reports-d532156b72765c21be5a29f73718af7e
* oft-no-repro-d532156b72765c21be5a29f73718af7e
The same target, but `build_2` uses the following containers:
* oft-setup-270ee492f18c5f71a0a3e1cffcb98f77
* oft-coverage-270ee492f18c5f71a0a3e1cffcb98f77
* oft-inputs-d532156b72765c21be5a29f73718af7e
* oft-crashes-d532156b72765c21be5a29f73718af7e
* oft-reports-d532156b72765c21be5a29f73718af7e
* oft-unique-reports-d532156b72765c21be5a29f73718af7e
* oft-no-repro-d532156b72765c21be5a29f73718af7e
The only difference is a unique oft-setup container.
In these examples, `oft` stands for *O*ne*F*uzz *T*emplate "setup" container.